tag:blogger.com,1999:blog-21239164885449058312024-03-05T02:11:03.827-08:00Agile Sadism: The "other" tool for cultural changeJonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-2123916488544905831.post-80562146954998634602016-09-08T13:22:00.000-07:002016-09-08T13:22:03.317-07:00So THIS is where I left this old blog! Hey! It's still working too!You may have noticed (as if anyone is actually reading this) that I've not posted in some time. No, I don't even have a bad excuse, although if you give me a bit I'll come up with something really good, involving pirates and ninjas.<br />
<br />
So where have I been? To quote one of my favorite fictional characters, Martin Blank: "I guess you could say I went west. You know, the way of Horatio Alger, Davey Crockett, the Donner Party...".<br />
<br />
If you must know, I've been working. I had an opportunity to join a small start-up style team working within a publicly traded company, which I jumped at the chance because it gave me a chance to further test out theories of how to successfully (and unsuccessfully) operate an innovation team within an established organization.<br />
<br />
And it has been an excellent learning experience, but as all good things must end it was time for me to move on to a different challenge. I'll be writing more on this experience in future postings but the one thing I did want to highlight first was the deep sense of camaraderie that developed within our team and the business unit we were tasked with supporting by any means necessary.<br />
<br />
I saw firsthand what having courage and a selfless lack of ego can do for bringing together a team that had deep experience aligning it's work with known business value.<br />
<br />
I also saw firsthand how an attitude of "By any means necessary" coupled with a strong commitment to the team could bootstrap a business unit from nothing to a strategic centerpiece of the growth strategy of a publicly traded company.<br />
<br />
The successes of this team I have had the privilege to work with cannot be found in any book or training class - it was the people that made the difference. They certainly made a difference to me. In future postings I'll discuss in greater detail what I saw from these people and how it made the team work, but for now I'm simply going to say that I will miss working with them and thank them for an excellent opportunity to learn and be successful.<br />
<br />
Vaya con dios, Saskia and Dwayne. I truly enjoyed working with you.Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-67282109320083701522014-02-06T22:53:00.000-08:002014-02-06T23:00:38.024-08:00Software Anti-craftsmanship<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
Today was the February installment of the Salt Lake Agile Roundtable (<a href="https://twitter.com/search?q=%23slagile&src=typd" target="_blank">#slagile</a>). Originally founded by Alistair Cockburn way back in the mists of time, it persist to this day as a place for some of the best conversations surrounding Agile that you can find anywhere.</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
If you've never been I'd highly recommend taking in at least one of the meetings. In past meetings there has been all sorts of interesting shenanigans, everything from the obliteration of hopeful doctoral dissertations to actual coloring sessions with crayons and everything (no, I'm not making that last one up - you had to be there)</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
One of the key elements of the meeting structure is that everyone is asked to bring a topic for discussion. Ideally it will be related to a challenge you are facing but with some of us old timers who've heard just about every kind of problem with software teams you can come up with we have a tendency to introduce topics that will provoke (hopefully) interesting discussions.</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
Or at least interesting arguments.</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
My topic today was inspired by a comment someone had made in a previous topic. What they said was "Well, yes, but a craftsman (software) would never do that". Waving an absolute like that in front of us has roughly the same effect that catnip does on cats, so of course I had to find out from the group exactly what they thought software craftsman ship was.</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
Thus I asked the question: "Exactly what does it mean to be a software craftsman? How can you detect the spoor of such an elusive beast?"</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
OK. Maybe I didn't use the term "spoor", but I should have. Would have given me a good excuse to break out a pith helmet in the middle of the meeting.</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
Of course it wouldn't be the Salt Lake Agile Roundtable if there wasn't a twist to the conversation. The twist of the day was provided by David Adsit (<a href="https://twitter.com/davidadsit" target="_blank">@davidadsit</a>) of <a href="http://www.pluralsight.com/training" target="_blank">Pluralsight</a>. David decided to take the contrarian view and present his list of really annoying things that those craftsmanship jerks do.</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
Without further ado, I give you David's list of "Software Anti-craftsmanship" qualities:</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
1. Wastes far too much time navel gazing<br />
2. Pointlessly delays the deliver of "good enough" code</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
3. Constanty renaming everything! Always with the renaming!</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
4. Fritters away valuable time changing existing code rather than working on new code</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
5. Treats the rest of us like second-class programmers</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
6. Constantly taking off for yet more useless training. Don't even get me started about all of these "Retreats"!</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
7. Imposes their philosophy about why the way they work is better without ever offering any actual evidence.</div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
<br /></div>
<div dir="ltr" style="background-color: white; color: #222222; font-family: arial, sans-serif; font-size: 13px;">
You know, I think we might have the beginnings of a manifesto on our hands here...</div>
Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-33515142584979135472014-01-30T11:02:00.000-08:002014-01-30T11:02:10.521-08:00An agile legacy. Or should that be "An Agile legacy"?<div>
A couple of years ago at <a href="http://www.agileroots.com/" target="_blank">Agile Roots</a> I was part of a panel discussion titled <a href="http://www.confreaks.com/videos/214-agileroots2009-panel-there-is-only-us" target="_blank">"There Is Only Us"</a>. The gist of the conversation is whether agile had reached the point where it was considered a best practice for the software industry.</div>
<div>
<br /></div>
<div>
As best I could tell, our consensus answer to that question was "Purple".</div>
<div>
<br /></div>
<div>
There's no question that awareness of this thing called "agile" has permeated the software industry. But the principles behind it? The point of it all? I'm not so sure.</div>
<div>
<br /></div>
<div>
According to a highly scientific survey of a few web sites I decided to google based on my own biases I can prove conclusively that the most common conversation about agile is "Why it didn't work for us".</div>
<div>
<br /></div>
<div>
But this entry is not about <a href="http://jimhighsmith.com/micromanaging-angst/" target="_blank">agile teen angst</a>. It's about legacy - what we influence, what we pass on.</div>
<div>
<br /></div>
<div>
For many years I taught martial arts as a personal passion. Even tried to make it my career a couple of times. If you're wondering how successful I was just note the fact that I blog about the software industry and not the martial arts industry.</div>
<div>
<br /></div>
<div>
But the one thing I did do well was teach. And the interesting thing I learned about teaching is that sometimes you influence people's lives for the better. Seeing those changes in the lives of my students fed my soul enough to motivate me to keep teaching for over 20 years.</div>
<div>
<br /></div>
<div>
Sorry, was waxing nostalgic for a moment there. No, that's not the legacy I'm writing about.</div>
<div>
<br /></div>
<div>
Last night I was chatting with<a href="http://danielspangler/" target="_blank"> Daniel Spangler </a>- a long-time friend and co-worker. Daniel is the kind of rock star developer that you build development teams around. I know this because I've done just that multiple times.</div>
<div>
<br /></div>
<div>
Unfortunately our last project terminated rather abruptly, so Daniel moved on to a new position that included...</div>
<div>
<br /></div>
<div>
<i>(insert screeching horror sound track here)</i></div>
<div>
<br /></div>
<div>
Management responsibilities! </div>
<div>
<br /></div>
<div>
O, the horror of it all!</div>
<div>
<br /></div>
<div>
As luck would have it, the company he joined was just in the initial stages of rolling out Scrum through their development teams. Daniel, still reeling from the shock of becoming management, decided that I'd be a good person to talk to about this whole agile thing. Of course him coming to me for advice was all the evidence I needed that he was still in shock.</div>
<div>
<br /></div>
<div>
Daniel: "So we're doing Scrum, and I don't know anything about it".</div>
<div>
<br /></div>
<div>
Me: (insert spit-take here) "Daniel, you've been practicing agile for years! What do you mean?!?"</div>
<div>
<br /></div>
<div>
Daniel: "Yeah, I know we've been doing it, but I don't know what all this stuff is called."</div>
<div>
<br /></div>
<div>
What's tragic about this is that there's a large contingent of the "Agile" (yes, I used the big "A" intentionally) community that would agree with Daniel's sentiment that he doesn't know "Agile", let alone Scrum. Daniel isn't the only one. I've visited many teams in the guise of an agile mentor. Invariably they would disclaim that they didn't know (or care about the names) of whatever flavor of agile you'd care to name but were shining examples of how agile teams really work.</div>
<div>
<br /></div>
<div>
Once I had wiped the water off of my keyboard Daniel and I got to work translating Scrum terminology into practices we'd been using for years. Then we stepped back and reviewed the principles behind those practices so he'd have a good basis of why Scrum does what it does, and why we diverged in various situations in the past.</div>
<div>
<br /></div>
<div>
The payoff came in the form of a short conversation we had last night:</div>
<div>
<br /></div>
<div>
Daniel: "So I agree that focus is a key element of agile" <i>(referring to our discussion that iterations provide a framework for the team to limit their focus to the work at hand)</i></div>
<div>
<br /></div>
<div>
Me: "Tell me more"</div>
<div>
<br /></div>
<div>
Daniel: "After drilling the team hard on better story definition at the beginning of the iteration we are seeing better velocity across multiple projects. Team members aren't wallowing around as much on what they should be working on" <i>(their team works on multiple projects simultaneously)</i></div>
<div>
<br /></div>
<div>
Me: "So is this a focus success story or iteration definition success story?"</div>
<div>
<br /></div>
<div>
Daniel: "Both, but ultimately it is about better focus. More concise stories translates into less interruptions during the iteration. Less interruptions equals more work being done. We're catching up on several chronically late projects"</div>
<div>
<br /></div>
<div>
Me: "Woohoo!"</div>
<div>
<br /></div>
<div>
Of course this conversation begs the question of "Why don't we see this sort of success happening more often when teams shift to various agile methodologies?"</div>
<div>
<br /></div>
<div>
Wait, I know the answer to this! </div>
<div>
<br /></div>
<div>
Experience. </div>
<div>
<br /></div>
<div>
Daniel, who has at least 10 years of experience working with teams practicing different flavors of agile (<a href="http://en.wikipedia.org/wiki/Scrum_(software_development)" target="_blank">Scrum</a>, <a href="http://en.wikipedia.org/wiki/Crystal_Clear_(software_development)" target="_blank">Crystal</a>, <a href="http://en.wikipedia.org/wiki/Extreme_programming" target="_blank">XP</a>) can tell immediately when something isn't right, even if he isn't always using using the right names for the dogma.</div>
<div>
<br /></div>
<div>
Contrast that with how agile adoptions typically work - companies hire external experts to provide training and mentoring, but don't invest in installing persistent expertise at the team level where the rubber hits the road. Is it any wonder why we see "We tried Agile but it didn't work for us" so often?</div>
<div>
<br /></div>
<div>
My hat is off to Daniel. Thanks to him, I have a new element of professional legacy that I can point to and admire. </div>
<div>
<br /></div>
<div>
Oh, and I guess I'll have to claim one less "Agile didn't work for us" story too.</div>
<div>
<br /></div>
<div>
<br /></div>
Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com2tag:blogger.com,1999:blog-2123916488544905831.post-13888005627001600582014-01-23T13:15:00.001-08:002014-01-23T13:15:59.901-08:00Startup Weekend Anthropology 101Let's kick things off with a quote:<br />
<br />
"I chose cultural anthropology, since it offered the greatest opportunity to write high-minded balderdash" - <a href="http://www.goodreads.com/work/quotes/1760881-palm-sunday" target="_blank">Kurt Vonnegut</a><br />
<br />
Last month I attended an event up in Ogden called <a href="http://startupweekend.org/" target="_blank">"Startup Weekend"</a>. I had heard various things about Startup Weekend through word-of-mouth channels but until this event I had not directly participated in one of these events. Thanks to one of my Agile colleagues <a href="https://twitter.com/mailekeone" target="_blank">Maile Keone</a> and local event organizer <a href="https://twitter.com/_AlexLawrence" target="_blank">Alex Lawrence</a> not only did I have a ticket to the event, but also very nice accommodations next to where the event was hosted.<br />
<br />
I didn't walk into the event planning on becoming a Startup Weekend anthropologist, but I certainly walked out as one. Over the next few blog entries I'll be rambling on about what I learned over the course of one weekend in Ogden.<br />
<br />
Being a Startup Weekend virgin, I wanted to preserve my opportunity to learn about the event organically so I made the decision to minimize my event pre-res... <i>*snort*</i><br />
<br />
Sorry, couldn't get through that sentence with a straight face. Let's try this instead:<br />
<br />
Being a Startup Weekend virgin I did the absolute minimum amount of work necessary to not look like a completely clueless buffoon when I showed up. Or at least I thought I did.<br />
<br />
When you look at the outward packaging of Startup Weekend you see the following:<br />
<br />
<span style="background-color: white; color: #626155; font-family: Arial, Helvetica, sans-serif; font-size: 15px; line-height: 25.5px;">Startup Weekends are weekend-long, hands-on experiences where entrepreneurs and aspiring entrepreneurs can find out if startup ideas are viable.</span><br />
<span style="background-color: white; color: #626155; font-family: Arial, Helvetica, sans-serif; font-size: 15px; line-height: 25.5px;"><br /></span>
Reading the above I made two assumptions. One was that a significant number of attendees brought in their business ideas and that there was a significant percentage of startups that launched as a result of Startup Weekend events.<br />
<br />
It's a good thing I do clueless buffoon well. I was wrong on both assumptions.<br />
<br />
But I'm getting ahead of myself. One of my goals for the event was to engage not as a technical resource but as a business resource - I'd bring in an idea, I'd pitch it, hopefully gather a team and see what happened. I also decided I was going to hack the idea pitch at the beginning of the event by not promoting how cool the business concept was but instead to promote how the team engaged with me would get a better event experience by delivering not one MVP by the end of the weekend - we'd deliver at least 4 or 5.<br />
<br />
This great idea of mine lasted maybe 15 minutes into the introductory presentation. What killed it was the admonishment of the event coordinator that you should not pitch your pre-conceived business ideas but instead pitch the problems you are interested in solving that others would also be interested in solving.<br />
<br />
It seems I wasn't alone in my mistaken assumptions. There were a number of other first-time attendees I talked to that had made the same assumption. It was interesting to see how many persisted in pitching their concept even after the suggestion to focus on an interesting problem. For the record, I trashed by carefully crafted pitch (after hours of rehearsals and timing practices) and pitched the underlying problem to see what sort of interest it would generate.<br />
<br />
None, as it turns out.<br />
<br />
But the story doesn't end there. As a matter of fact, that's where the real story begins.<br />
<br />
After having my grandiose idea completely ignored I started looking at other ideas that I could jump into and work on. One in particular caught my eye. The idea centered around building some sort of a mobile device multi-player game. This idea was pitched by a 17 year old that had attended 3 prior Startup Weekend events. It wasn't the idea that I found interesting - it was who was pitching it. Honestly - how many 17 year olds do you know that show up at an event like this?<br />
<br />
So I wandered over and introduced myself, intending to provide expertise as a business and process expert. I didn't even get to the part where I explained what I was good at before he had handed me an assignment.<br />
<br />
It wasn't the assignment that made me walk away from this project. From his perspective I am sure he thought it was the right thing to be doing. But it was clear from that one interaction that I'd have to do a lot more work from a "managing" perspective to get things moving toward a successful presentation at the end of the weekend. And that realization made me question whether it was a good idea for me to be walking into any team there and imposing my experience on them.<br />
<br />
I know, the hubris is just dripping from that last paragraph, isn't it? Let's set aside for the moment any discussion of the "value" of my skill set and just focus on personality. My personality is such that I gravitate towards leadership of any group I'm involved in. For better or worse it is how I operate. But I realized in that moment that managing a team to deliver isn't something I really needed or wanted to experience at this event. What I really wanted to experience was how these ad-hoc teams fared over the course of the weekend.<br />
<br />
And was I ever glad I did. In that moment I became the Startup Weekend incarnation of <a href="http://en.wikipedia.org/wiki/Margaret_Mead" target="_blank">Margaret Mead.</a><br />
<br />
Stay tuned for Startup Weekend Anthropology 102: The highest of highs, the lowest of lows<br />
<br />
<br />
<div class="entry-content">
<div style="color: #626155;">
<span class="big rockwell" style="color: #524501; font-size: 28px; line-height: 42px;"><cufon alt="Startup " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 100px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 123px;" width="123"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="Weekends " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 144px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 167px;" width="167"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="are " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 49px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 72px;" width="72"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="54-hour " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 108px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 131px;" width="131"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="events " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 91px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 114px;" width="114"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="where " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 88px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 111px;" width="111"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="developers, " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 160px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 183px;" width="183"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="designers, " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 143px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 166px;" width="166"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="marketers, " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 145px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 168px;" width="168"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="product " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 109px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 132px;" width="132"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="managers " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 136px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 159px;" width="159"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="and " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 56px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 79px;" width="79"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="startup " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 98px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 121px;" width="121"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="enthusiasts " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 151px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 174px;" width="174"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="come " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 79px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 102px;" width="102"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="together " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 118px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 141px;" width="141"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="to " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 32px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 55px;" width="55"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="share " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 78px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 101px;" width="101"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="ideas, " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 83px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 106px;" width="106"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="form " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 69px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 92px;" width="92"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="teams, " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 90px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 113px;" width="113"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="build " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 75px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 98px;" width="98"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="products, " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 128px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 151px;" width="151"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="and " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 56px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 79px;" width="79"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="launch " class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 94px;"><canvas height="27" style="height: 27px; left: -1px; position: relative !important; top: 2px; width: 117px;" width="117"></canvas><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon><cufon alt="startups!" class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 28px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 112px;"><canvas height="27" style="-webkit-text-stroke-width: 0px; background-color: white; color: #524501; font-family: Arial, Helvetica, sans-serif; font-size: 1px; font-style: normal; font-variant: normal; font-weight: normal; height: 27px; left: -1px; letter-spacing: normal; line-height: 1px; orphans: auto; position: relative !important; text-align: start; text-indent: 0px; text-transform: none; top: 2px; white-space: normal; widows: auto; width: 134px; word-spacing: 0px;" width="134"></canvas><cufontext style="-webkit-text-stroke-width: 0px; background-color: white; color: #524501; display: inline-block !important; font-family: Arial, Helvetica, sans-serif; font-size: 1px; font-style: normal; font-variant: normal; font-weight: normal; height: 0px !important; letter-spacing: normal; line-height: 1px; orphans: auto; overflow: hidden !important; text-align: start; text-indent: -10000in !important; text-transform: none; white-space: normal; widows: auto; width: 0px !important; word-spacing: 0px;"></cufontext></cufon></span></div>
</div>
<br />
<h1 class="entry-title" style="color: #e7730c; font-family: Arial, Helvetica, sans-serif; font-size: 18px; font-weight: normal;">
<cufon alt="About" class="cufon cufon-canvas" style="display: inline-block !important; font-size: 1px !important; height: 18px; line-height: 1px !important; position: relative !important; text-indent: 0px !important; vertical-align: middle !important; width: 53px;"><cufontext style="display: inline-block !important; height: 0px !important; overflow: hidden !important; text-indent: -10000in !important; width: 0px !important;"></cufontext></cufon></h1>
Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-82582318915908216912013-12-10T20:17:00.000-08:002013-12-10T20:17:13.436-08:00Learning against my will. Oh, and there was this Lean Startup Conference thing...Sometimes this learning thing isn't all it is cracked up to be.<br />
<br />
Take today's example. I found myself down at the <a href="http://www.mbrcslcc.com/mbic" target="_blank">Miller Business Innovation Center</a> to watch their local webcast of the <a href="http://leanstartup.co/" target="_blank">Lean Startup Conference</a> happening this week in San Francisco. I was all set to settle in, have a couple epiphanies, and then I'd be able to knock off for the day with a new "I learned something" badge earned.<br />
<br />
Wrong.<br />
<br />
I put at least some of the blame on Alistair and the Salt Lake Agile Roundtable gang. It was from them that I picked up the habit of a) always be ready to articulate at least one learning moment from any learning event, and b) actually write down your learning moments so they are reinforced at the moment they are strongest.<br />
<br />
I knew I was in trouble about 5 minutes after the first session started. It was <a href="https://twitter.com/kmin" target="_blank">Kathryn Minshew</a> - "Getting Users Out of Nowhere". Normally I'd coast through topics like this with my mental cruise control on. Not because they were not interesting or relevant. They are. But that's not an area I've often been at a loss for ideas, so I hadn't pursued learning more.<br />
<br />
Well, you know the universe loves moments like this. Or at least the universe that I inhabit certainly does. Since I'm a fan of Norse mythology I can picture with amazing clarity Odin sharpening up Gungnir while Thor is off to the side giving Mjolnir a last bit of polish while glaring in my general direction.<br />
<br />
Ok. Maybe it wasn't Gotterdamerung. But what did happen was that a part of my brain that doesn't like the mental cruise control slammed on the brakes and said "Hang on! Did you hear that?!?"<br />
<br />
In this particular case it was Kathryn's discussion of how to become your own PR machine. Upon hearing that I dutifully recorded the "aha" moment (yes, it's below if you really want to know). With that aha safely recorded I patted myself on the back and prepared to settle back into cruise control.<br />
<br />
Never got there. That same part of my brain that slammed me out of cruise control said "What if she said something else interesting before this?". Muttering vague obscenities under my breath I called up my mental playback department to find out if there had been anything else interesting that I had missed the first time through.<br />
<br />
And of course there was. The other tidbit was about making it insanely easy for others to engage in word of mouth advertising for you.<br />
<br />
After admitting to myself that I had let a learning moment actually slip by there was no chance that I'd be able to descend back into mental cruise control. I was saddled up for the full ride.<br />
<br />
And what a ride it was. I recall actually being irritated by the end of the webcast at the audacity of the conference organizers to schedule that many impactful sessions in a row. What ever happened to tossing a few stiffs in there so you could have time to wander over to the mental dressing room to see how well the new ideas fit?<br />
<br />
I'm glad to say my irritation was short-lived. Yes, the learning experience had a lot to do with my mood alteration. So did this parting shot from my mental brake-slammer:<br />
<br />
"Gee, you're not getting OLD, are you? Only OLD people stop learning"<br />
<br />
In case you thought you were going to get out of this blog entry without having to hear me blather on about the actual things I learned (or re-learned), think again.<br />
<br />
I will give you this warning. Context counts in learning moments. If you don't have a shared context for the new idea it will not have the same impact. I'll do my best to convey context but I can promise you that whatever I have to say will be no substitute for you to have your own learning experience from these presentations. Hopefully they will be posted publicly at some point so you can if you missed the conference.<br />
<br />
What I learned (or re-learned) today from the Lean Startup Conference:<br />
<br />
Kathryn Minshew (The Muse) - Acquiring Your First Users Out of Thin Air<br />
<br />
<ul>
<li>"Ask for word of mouth from your customers and make it insanely easy to do". It was the insanely easy part that got me thinking.</li>
<li>"Tell a good, clear, easy-to-report story". When you're working with bloggers / news outlets to get your message out stories are much more effective than data or marketing statements. Those stories should whenever possible relate to current events / trends</li>
<li>(Regarding her advice to offer to write posts / articles for blogs and news outlets) "Harvard Law Review rejected my offered stories for a year before they accepted one. Persistence matters.</li>
</ul>
<div>
Alexis Ringwald (LearnUp) - How to Build the Product When You're Not the User</div>
<div>
<ul>
<li>Her team spent 5 months visiting people in unemployment lines learning what the people there needed.</li>
<li>Having a "Contact Us" button was not enough - they built a way to stay engaged with their users.</li>
<li>The whole team recently took a field trip to Mendota, CA (39% unemployment) to continue to learn about what was and was not working.</li>
</ul>
<div>
Daina Linton (Fashion Metric) - Work With Customers Before You Write Any Code</div>
</div>
<div>
<ul>
<li>Initial idea (having a fashion expert available to advise when shopping) wasn't what people needed. By using open-ended questioning they learned what was needed for Men was a way to help them find clothes that actually fit.</li>
<li>By using a Concierge model (human in the loop) as opposed to building applications they were able to go from validating the new idea to confirming a return rate of 0% on shirts sold via their fitting model. </li>
<li>Their initial product consisted of a web site that offered a better shirt fitting experience. Only call to action was to ask for permission to have a 10 minute phone conversation about what they needed.</li>
</ul>
<div>
Christie George (New Media Ventures) - Funding for Lean Impact</div>
</div>
<div>
<ul>
<li>Applying the principles of "Fail Fast" and "Fail Forward" to social challenges means that real people are failed. Make sure the failure stays where it has positive value.</li>
<li>Social change takes a long time (interracial marriage as an example). Social startups can accelerate those feedback loops only so much.</li>
<li>Social funders (charitable organizations) are very risk adverse. Need to find a way to incentivize risk.</li>
<li>Create a culture where the truth is incentivized (example given was Unreasonable Institute's practice of reporting their investment decision failures).</li>
</ul>
<div>
Ari Gesher (Palantir) - Preparing for Catastrophic Success</div>
</div>
<div>
<ul>
<li>The hard things to deal with are getting real estate and leadership. Both require at least a 6 month horizon. Only the leadership part is interesting (his words in the presentation).</li>
<li>Want internal leaders? Pick your leaders, then give them a few people to lead immediately. Support them with a forum that they can discuss their challenges and problems. Then let them lead.</li>
<li>In the midst of growth is no time to build command and control leadership. Leaders need to be communication nodes, facilitating communication for their teams, coordinating with other teams.</li>
<li>Culture is an emergent property of the people you hire. Thinking "Will this person fit the culture" is not as important as thinking "How will this person enhance the culture"</li>
<li>Indoctrinate culture from the day people start. Don't leave it up to chance.</li>
<li>Final thoughts - "If it hurts, you're doing it right"</li>
</ul>
<div>
Steve Blank (Stanford / Berkley / Columbia) - Evidence-based Entrepreneurship</div>
<div>
<ul>
<li>Steve scared me a bit. His presentation centered around the fact that there are now actionable metrics around startups, which on the surface seems a good thing. But there's no lack of cautionary tales of metrics gone wrong...</li>
<li>Startups are not smaller versions of companies. They are temporary organizations that exist to find a scalable business model. Only when they find that model can they become "companies"</li>
<li>His template for a startup is a Business Model Canvas + Customer Development Lab + Agile Engineering and Dev methodology</li>
<li>His Lean Startup class at Stanford is experiential - you will talk to at least 100 customers during the 10 week course.</li>
<li>NSF approached him to put together a class for the NSF. That grew into a metric framework to observe the progress of teams</li>
<li>Having that metric framework allowed Steve to come up with the "Investment Readiness Measurement" - a means of determining what pre-funding stage a startup was in. Modeled off of the NASA Technology Readiness Scale</li>
</ul>
<div>
Nikhil Arora & Alejandro Velez (Back To The Roots) - Using Kickstarter to Run an MVP</div>
</div>
<div>
<ul>
<li>After starting with a "Grow your own mushroom" home kit they decided to bring an aquaponics idea to market - a system where fish waste was used to grow a small herb garden. Turned to Kickstarter to fund it. Had $248,000 in funding within 30 days.</li>
<li>They learned along the way the cost of rushing to market (faulty pump, unclear packaging). Their lesson learned that it was less expensive to deal with those things before rushing to market, not after.</li>
</ul>
<div>
Keya Dannenbaum (ElectNext) - Learning to Be and Organization that Pivots</div>
</div>
<div>
<ul>
<li>One of the most common statements about entrepreneurship is "Follow Your Passion". It's wrong. She followed this up with data about the effect of emotional "passion" (it burns out) versus dedicated practice. Out of the two, practice is what matters, not passion.</li>
<li>Their first MVP took 18 months to develop, and it is no longer in use. Their second took 6, and their third took a few weeks. Only the third has proven a repeatable revenue model, and the only "Product" is Google docs and an email address database.</li>
<li>But those first two products are not failures. They were vital practice for their team to get better at what matters as a startup. Previously there was a lot of fear associated with pivots. Over time the pivots became something embraced - it meant progress towards a goal.</li>
</ul>
<div>
John Shook (Lean Enterprise Institute) - Lean Startup--From Toyota City to Frement to You</div>
</div>
<div>
<ul>
<li>John started off by following the lead of the MIT research team that spawned the Lean Institute. He wanted to work for a Japanese car manufacturer to learn their management methods. Only one would hire him - Toyota. At the time he was the only westerner working at a Japanese auto plant.</li>
<li>His statement about Lean to the whole group was powerful. "This (Lean) is a Learn By Doing process. You learn by doing it. With respect to everyone here, attending conferences and reading books will not get you there".</li>
<li>In 1 year the factory selected for the joint GM/Toyota venture went from last in quality to first (UAW rated)</li>
</ul>
<div>
Brad Smith (Intuit Software) - Lean Leadership Lessons</div>
</div>
<div>
<ul>
<li>This was by far my favorite session. Of course I am defining "favorite" as "The one story I'd most like to find out if they are full of BS or really meant what they said".</li>
<li>Creating an innovation culture was a deliberate effort and takes buy-in across the whole company. The function of management is most importantly to "Find a way to get to Yes".</li>
<li>They host an annual incubation week - teams are allowed to work on anything they see fit, company has resources deployed to assist them (legal, etc).</li>
<li>Their projects are classified into three tiers - Horizon 1 (immediate revenue generators), Horizon 2 (Established business model with actual customers needing to be curated into a full offering), Horizon 3 (The idea/MVP area)</li>
<li>Their team cultures are different based on their tier of product. And they encourage that to be the case.</li>
<li>Most interesting to me was the acknowledgement that the Horizon 3 products require a more risk-tolerant environment to thrive, and Intuit delivers it to them.</li>
<li>Hugh Molosti is their primary idea guy over the years and has a 7 figure incentive package to keep him from going anywhere else. What other company is that proactive in keeping their best idea people?</li>
</ul>
<div>
<br /></div>
</div>
<div>
<br /></div>
</div>
Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-19768796938037199762013-11-18T16:10:00.001-08:002013-11-18T20:51:43.029-08:00Of Liaisons, ball bearings, fetzer valves and failuresThere's a scene from the movie "Fletch' when Chevy Chase is posing as an aircraft engine mechanic and is being grilled about why he'd need ball bearings. His reply: "Come on guys, it's all ball bearings these days!"<br />
<br />
\No, I'm not going to talk about ball bearings or even Fetzer valves (inside joke for the Fletch fans out there).<br />
<br />
To paraphrase, "Come on guys! It's all patterns these days!"<br />
<br />
But before I do, a bit of history. First, the earth cooled. Then dinosaurs roamed the planet.<br />
<br />
Too far back? OK. We'll just set the wayback machine to 1977.<br />
<br />
An architect by the name of <a href="http://en.wikipedia.org/wiki/Christopher_Alexander" target="_blank">Christopher Alexander</a> published a book titled "<a href="http://en.wikipedia.org/wiki/A_Pattern_Language" target="_blank">A Pattern Language: Towns, Buildings, Construction</a>". Although reports vary on the influence it had on the Architecture industry, it is commonly cited as the inspiration design patterns in software architecture, interaction design and many other fields.<br />
<br />
So what was the big deal? He introduced the concept of a <a href="http://en.wikipedia.org/wiki/Pattern_language" target="_blank">Pattern Language</a>. Pattern languages gave a structure to identifying common problems along with their best practices solution(s) in specific disciplines. This allowed valuable information about common problems and solutions to be communicated much more rapidly and reliably than ever before.<br />
<br />
As a software architecture-ish kinda guy, I cut my teeth on the <a href="http://en.wikipedia.org/wiki/Design_Patterns" target="_blank">Gang of Four's Design Patterns book</a>. Then as I started looking around at other disciplines I realized that they had their own pattern languages, and if I took the time to understand them I'd have a much better understanding of the problems and problem solving approaches to these other disciplines - think of it as an abstract version of the Rosetta stone<br />
<br />
Imagine my delight when I discovered that there were <a href="http://en.wikipedia.org/wiki/Organizational_patterns" target="_blank">organizational patterns</a> - a pattern language devoted to problem solving challenges in organizational structures, something we have to do from time to time in this business.<br />
<br />
Odds are good that you're very familiar with at least one of these, even if you don't know it as an organizational pattern. Ever hear anyone say "We're running a <a href="http://en.wikipedia.org/wiki/Skunkworks_project" target="_blank">skunk works</a> team"?<br />
<br />
Yep. It's an organizational pattern.<br />
<br />
During a recent <a href="http://www.agileroots.com/" target="_blank">Agile Roots 2014 </a>planning session I was talking with Lory Maddox (RN extraordinaire and mother of Ruby guru and Clean Coder evangelist <a href="http://patmaddox.com/" target="_blank">Pat Maddox</a>) about her current job, which is taking new patient interaction innovations and operationalizing them to work within the highly regulated environment of clinical medicine.<br />
<br />
As she was telling a story about how her team averted a logistic nightmare by stopping the release of a new communication solution that had not been adapted by her team for deployment into the highly regulated clinical medicine environment, I realized that her team (whether they realized it or not) were implementing an organization design pattern I like to call "Operationalizing".<br />
<br />
Operationalizing: A team with deep experience in a specific (usually highly regulated) environment that has the skills and the responsibility for adapting new solutions (software, process, etc) in such a way that the new solution can be deployed successfully within the target environment.<br />
<br />
<i>Note: I have not found definitive literature on the name of this pattern, so I get to call it what I like for now. Comment if you can point me to something authoritative.</i><br />
<br />
I know what you're thinking. No, we haven't gotten to the actual point yet. We're close, I promise! Don't get me wrong, the concept is very interesting, but it isn't the one I wanted to talk about. So why did I even take the time to mention it?<br />
<br />
Well, because thinking about how the Operationalizing pattern would play out was the trigger for putting my finger on how I've failed to properly apply the Liaison pattern.<br />
<br />
Let's go back to the <a href="http://en.wikipedia.org/wiki/Skunkworks_project" target="_blank">SkunkWorks</a> pattern for a moment (quietly, <a href="http://money.cnn.com/magazines/fortune/fortune_archive/2000/03/06/275258/index.htm" target="_blank">we don't want Lockheed suing us</a>).<br />
<br />
The SkunkWorks pattern is a very common organizational approach these days to attempt to solve the problem of <a href="http://en.wikipedia.org/wiki/Disruptive_innovation" target="_blank">innovation</a>. Look at any large company you'd care to point to. Odds are very high that they have at least <a href="http://www.nytimes.com/2011/11/14/technology/at-google-x-a-top-secret-lab-dreaming-up-the-future.html?pagewanted=all&_r=0" target="_blank">one</a> SkunkWorks <a href="http://online.wsj.com/news/articles/SB109459258888411589" target="_blank">team running</a>, <a href="http://fordsvl.com/research.html" target="_blank">maybe more</a>. My former employer <a href="http://www.fastcompany.com/3002948/walmarts-evolution-big-box-giant-e-commerce-innovator" target="_blank">Walmart was no exception</a>.<br />
<br />
When I was with Walmart this was the organizational pattern that we used to restructure the Mobile Applications group. Or was it?<br />
<br />
On the surface, yes. But we broke a few key rules of the SkunkWorks pattern - we did not completely segregate the team from the rest of the organization, nor did we completely decouple our infrastructure from the larger organization. Although I'm of the opinion that we could have done more to segregate the team the same was not true regarding the infrastructure. Because we were building live mobile apps that customers were using to buy real things from Walmart, we didn't have a lot of choices regarding our production infrastructure.<br />
<br />
And this is where the <a href="http://en.wikipedia.org/wiki/Liaison_officer" target="_blank">Liaison</a> pattern comes into the story. If you were paying attention a few paragraphs back you'll see that I actually used the dreaded "F" word in reference to myself.<br />
<br />
One of the first external teams I met with was the InfoSec group - this was the team responsible for insuring that all production code met industry and company security standards. As you'd expect with any large organization, the InfoSec team was a single siloed team that evaluated and validated the output of several teams including our Mobile Applications group.<br />
<br />
Here's the sad part. In my first meeting with them I explained how we were departing from the previous practice of months-long release cycles to a much faster cycle. When they indicated that their process didn't allow for that fast of a cycle I told them about the Liaison pattern and how it could be used to great success. After confirming that they all liked the idea I assured failure by making the foolish assumption that they'd actually do something about it.<br />
<br />
What I should have done in that situation was to put "find a way to get InfoSec to give us a liaison" at the top of my priority list.<br />
<br />
Back to the Liaison pattern. Never heard of it? You'll have to be a student of military organizational logistics to have come across the same definition that I have. In military circles, a Liaison is a person (or persons) that are a member of one group within a military organization but are assigned to be part of another group for the express purpose of helping that group to effectively interact with their "home" group. The pattern is most often implemented in situations where the "other" group operates at a much faster pace than the other group (e.g. Special Operations teams conducing operations in the same areas as conventional forces).<br />
<br />
Examples: <a href="http://en.wikipedia.org/wiki/Forward_air_control" target="_blank">Forward Air Controller</a>, <a href="http://en.wikipedia.org/wiki/Liaison_officer" target="_blank">Liaison Officer</a><br />
<br />
Had I made it a priority to work with InfoSec to have a member of their team assigned to ours it probably would not have made much of a difference in the early days of that engagement, namely because we were successful at pushing back on their process thanks to <a href="http://orgpatterns.wikispaces.com/PatronRole" target="_blank">Executive Sponsorship</a> (yet another organizational pattern). Where it would have made a huge difference was when that same executive sponsorship shifted and we were no longer able to keep InfoSec from slowing down our cycle time.<br />
<br />
By the way, that whole slowdown thing? That's an organizational pattern too - <a href="http://c2.com/cgi/wiki?OrganizationalAntibodies" target="_blank">Organizational Antibodies</a>. I'll be talking about that one in a future posting.<br />
<br />
The moral of the story - <a href="http://en.wikipedia.org/wiki/Organizational_patterns" target="_blank">Organizational Patterns</a>! Learn them, learn to use them if you care about being effective. Most importantly, learn how not using them will have a negative impact on your team(s).Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-3233119684367213202013-10-29T11:06:00.000-07:002013-10-29T12:09:05.172-07:00Getting political with Agile SadismI was on my way home from a medical appointment the other day and for some unknown reason decided that I needed to have a little talk radio background noise. After tuning into the local NPR station I was all set to disengage my thinking brain from my ears when I heard the interviewee say "Without common pain there is no chance to achieve real change in an organization."<br />
<br />
<i>Cue cinematic double-take record scratching sound.</i><br />
<br />
Did I really just hear that? On an NPR talking heads program?<br />
<br />
After a little research I discovered that the talking head in question making this point was no less than Mike Leavitt - former Governor of Utah (amongs many other positions I didn't bother to go look up) and the point he was making was in his new book entitled "Finding Allies, Building Alliances".<br />
<br />
For those of you worried about being bored to death by a book report, fear not. I have yet to pick up the book. You'll just have to get by with being bored to death by my thoughts on what I learned from that interview.<br />
<br />
If you haven't looked at the title of the blog recently, this would be a good time to do so. Go ahead - I'll give you a minute.<br />
<br />
Done? Great. As you'd imagine, the fact that pain is an effective tool in the political arena isn't a huge surprise. What was a surprise was the fact that he acknowledged it as such. What was even a bigger surprise is that he went on to describe a situation where his approach failed.<br />
<br />
See why I was surprised? Hearing a politician (or at least a former one) acknowledge not only the fact that he's applied "Machiavellian" techniques to get things done but actually admit that he experienced failure was the true eye-opener for me.<br />
<br />
Sounds a lot like a reflection session, doesn't it?<br />
<br />
What he "learned" from his failure was that not all of the stakeholders in a particular situation felt a common pain. As a result that same stakeholder ended up derailing the effort because they were better off maintaining the status quo.<br />
<br />
Of course we'd never see such a thing in the software development industry, would we?<br />
<br />
It is always instructional to see how similar problems are solved in different contexts. As this was the first time I've heard of a formalized approach to solving difficult problems in the political world I wanted to see what could be applied to my industry. Fortunately I was able to find the "Too Long; Didn't Read" book summary to get the big picture:<br />
<br />
<b>1. A Common Pain—a shared problem that motivates different people/groups to work together in ways that could otherwise seem counterintuitive. </b><br />
<div>
<br /></div>
<div>
Absolutely. Of course no virtuous person would ever consider actually manufacturing these common pains to get things done, right?</div>
<div>
<br /></div>
<div>
<b>2. A Convener of Stature—a respected and influential presence who can bring people to the table and, when necessary, keep them there.</b></div>
<div>
<br /></div>
<div>
If I were translating these points into the software domain (which of course I am) I'd say that this is the equivalent to the concept of an Executive Sponsor</div>
<div>
<br /></div>
<div>
<b>3. Representatives of Substance—collaborative participants must bring the right mix of experience and expertise for legitimacy and have the authority to make decisions.</b></div>
<div>
<br /></div>
<div>
This was a good reminder to me that the twin characteristics of recognized experience and decision making authority are key for all participants.</div>
<div>
<br /></div>
<div>
<b>4. Committed Leaders—individuals who possess the skill, creativity, dedication and tenacity to move an alliance forward even when it hits the inevitable rough patches.</b></div>
<div>
<br /></div>
<div>
Since problems within the software domain tend to be smaller in scope to the challenges government groups face, I'd say that we'd see this be the same group as with point</div>
<div>
<br /></div>
<div>
<b>5. A Clearly Defined Purpose—a driving idea that keeps people on task rather than being sidetracked by complexity, ambiguity and other distraction.</b></div>
<div>
<br /></div>
<div>
Definitely an important point for our industry considering how common it is for our teams to have split responsibilities.</div>
<div>
<br /></div>
<div>
<b>6. A Formal Charter—established rules that help resolve differences and avoid stalemates. </b></div>
<div>
<br /></div>
<div>
I've decided I don't know how I feel about this one yet. My initial reaction is that establishing rules is counter-productive to solving a problem quickly, but as I thought about it more I realized that the teams that I'd point to as not needing rules were actually operating under a self-generated set of rules learned from prior experiences.</div>
<div>
<br /></div>
<div>
<b>7. The Northbound Train—an intuitive confidence that an alliance will get to its destination, achieve something of unique value, and that those who aren’t on board will be disadvantaged.</b></div>
<div>
<br /></div>
<div>
This was probably my most valuable takeaway from this list. When you think about it, it is nothing more than a "pain" generated by the problem solving process. But it is also a particularly wide-reaching pain that if properly applied can increase the "rejection rate" of the solution across the wider organization.</div>
<div>
<br /></div>
<div>
<b>8. A Common Information Base—keeps everyone in the loop and avoids divisive secrets and opaqueness.</b></div>
<div>
<br /></div>
<div>
This is not exactly news for our software world (Information Radiators, Sunshine, etc), but it is a good reminder for me as I have a tendency to not put as much effort into these tools/process as they deserve.</div>
<div>
<br /></div>
<div>
So I'm sure at some point I'll pick up the book and read it. It's probably worth your time to do the same, especially if you are (as I am) a student of seeing similar problems solved in different environments.</div>
<br />Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-88352923850487104262012-04-02T21:58:00.000-07:002012-04-02T21:58:32.485-07:00Care and feeding of feedback loops<div class="p1">So, I have to brag just a bit. Frequent readers will recall that from time to time I post about the teams I am currently working with. For those of you suffering from "too long, didn't read" syndrome, I'll sum up the back story.</div><div class="p1"><br />
</div><div class="p1">The mobile applications group I work with consists of 5 different development teams - one back end services team and four client platform teams (iOS x 2, Android, Mobile Web). Although each of these teams have some really top notch people on the team, they were challenged from the process perspective when I joined the group. </div><div class="p1"><br />
</div><div class="p1">Our Android team was the first to launch with a structured methodology based on Alistair Cockburn's <a href="http://alistair.cockburn.us/Just-in-time+methodology+construction" target="_blank">"methodology tuning"</a> technique. The team is in the final stages of their first release using their shiny new methodology and speaking personally, I really am quite proud of what the team has accomplished. </div><div class="p1"><br />
</div><div class="p1">One accomplishment in particular was interesting enough that it warranted a write-up here. As mentioned above, the team is in their final stages of delivering their first release of a shopping application for the UK based grocery store chain. As this was the first time a native mobile application was being released for the UK market by our group, the leadership team decided that formal usability testing was warranted. </div><div class="p1"><br />
</div><div class="p1">Interesting thing about performing usability testing for an application to be deployed in the UK, the usability testing took place in - you guessed it, the UK. With the exception of the Product Owner, the whole development team is based in the US. Ideally we would have sent the whole team over to observe the usability testing, but given the distance the team decided to send their UX Designer over to represent the group.</div><div class="p1"><br />
</div><div class="p1">The choice was a good one. The UX Designer took copious notes of the usability testing, noting equally the things that users were pleased with and things that didn't work so well. These notes were then transferred to the team at the close of the first day of testing, who in turn immediately started poring through the notes.</div><div class="p1"><br />
</div><div class="p1">Here's the good part. Once the team was through the UX Designer's notes, they decided that they were going to fix a number of issues immediately and have the updated application ready for users at the start of the second day of usability testing. And they delivered.</div><div class="p1"><br />
</div><div class="p1">Note that I didn't say that the Product Owner requested the fixes, nor did the team responsible for usability testing. The decision to make the changes in time for the next day of testing was made entirely within the team. For those looking for some measure of team ownership of an application, you could do a lot worse than using this as a benchmark.</div><div class="p1"><br />
</div><div class="p1">Day 2 of usability testing dawns, and a new tested version of the application has been delivered to the usability lab. Prior to the team working in formalized iterations it is questionable whether they would have felt confident to turn around a new release of the application within a single night. Thanks to several iterations of practice at delivering a working application to stakeholders (the team's definition of "done - done" at the end of an iteration) gave them the experience and confidence to crank out a new release in short order.</div><div class="p1"><br />
</div><div class="p1">I know what you're thinking. "Wonderful, they can iterate and release quickly. Look how 'agile' they are. Whoopie.", right?</div><div class="p1"><br />
</div><div class="p1">Well, yes. They are 'agile'. Right on the front page of the Agile Manifesto it says "Respond to change over following a plan". All of the iteration / release conventions the agile community holds dear is rooted in this principle.</div><div class="p1"><br />
</div><div class="p1">But there's more to the story than that. Right below that "respond to change" line is "Customer collaboration over contract negotiation". What seems to be lost on most of our industry is the fact that the word "collaboration" means interact, not guess. Teams that interact directly with customers on a frequent basis are getting the single most important feedback there is - actual feedback from real customers using the application.</div><div class="p1"><br />
</div><div class="p1">Because the team had improved their ability to deliver frequently, they put themselves in a position to take the best possible advantage of that critical feedback loop. Prior to this it was difficult (not impossible, but still difficult) for the US based development team to interact directly with intended customers in the UK. In interviewing the team after the fact it was clear to them the value of having that customer interaction thanks to one of the team being on the spot.</div><div class="p1"><br />
</div><div class="p1">Without the team directly involving themselves in the usability testing they would have received the resulting reports in due course, but they would have missed out on the opportunity to close the that critical feedback loop with their customers. A feedback loop that was particularly difficult for the team to close prior to this usability testing event. </div><div class="p1"><br />
</div><div class="p1">I think that the best news of all is that I can't take any credit for the team taking advantage of user testing in the way they did. I didn't even know what their plan was until I heard about it after the fact from the team project manager, <a href="http://www.linkedin.com/pub/michael-buckland/0/7b1/347" target="_blank">Michael Buckland</a>. Michael is much more than the project manager for the team - he's also taken over agile coaching responsibilities for the team, and has done a great job in that role. So much so that I may even forgive him at some point for being such a Scrum fanatic. </div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com1tag:blogger.com,1999:blog-2123916488544905831.post-17596191647561142712012-03-12T11:27:00.000-07:002012-03-12T11:27:21.086-07:00Who says I ain't agile?<div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">*sigh*</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I really should know better by now, but I still remain surprised that people in the Agile business seem to miss the fact that there is more than one agile methodology when they are claiming "You're not agile unless...".</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">The current subject of my angst is a blog posting<b style="font-style: italic;"> </b><a href="http://www.softwareandi.com/2012/01/10-signs-that-your-team-isnt-really.html" target="_blank">(10 Signs that Your Team Isn't Really Agile)</a>. For the record, I actually do think it is a thought provoking commentary for teams that are beginning the adoption of Scrum and looking for guidance on whether they are coloring within the lines or not. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Where I take issue with the article is the fact that the author cites examples of practices and techniques that are primarily associated with Scrum and claims that if you're not following them as prescribed, you're not agile. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Well, I'm not quite ready to turn in my agile secret decoder ring just yet.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I chose to dissect this specific article because right off the bat it was a particularly egregious violation of the agile equivalency principle. Yes, I know it's a math term, just bear with my nerdiness for a moment here. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Right in the opening paragraph the author states "With all the hype in the software industry about Agile, Scrum, and so on...". Or, in formulaic terms:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Agile = Scrum (false - Scrum is an instance of agile, not a peer)</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Scrum = So on (false - 'So on' is undefined)</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">OK. Now that I've appeased my inner math nerd, let's get to the interesting part, dissecting the 10 points raised in the article. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i>Important Note: It is entirely possible that I misinterpreted what the author wrote, so I'd invite you to read the original blog so you have both sides of the story. </i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i><br />
</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">1. Your team is not responsible for the whole story.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In the article the author discusses both the fact that Agile teams should be cross-functional and that no value is delivered to the customer until the full story is delivered. All good so far. But then the author makes the statement that although it is possible to have a successful development process without cross functional teams, it simply isn't agile.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Not quite.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Every agile methodology in current use has some means identified for scaling up teams. Many studies have concluded that the optimal Agile team size is somewhere between 4 and 8 members. Teams working on larger projects (especially within enterprise settings) will frequently own different parts of a single user story. As long as the teams deliver on their parts and collaborate as needed to insure the full story is delivered there is nothing un-agile about shared ownership of a story.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">2. Testing is done by another team.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In the description it says "code complete is not done". Looks good so far. Next it states that if QA is another team the team isn't cross-functional. No argument here. Work that isn't tested and integrated isn't considered done. Also looks good.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">But that's it. It isn't stated directly, but the implication certainly seems to be "if QA is a separate team, you're not Agile".</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In checking the Agile Manifesto, I don't see a thing in there about QA has to be on the same team. Is it a good idea? Absolutely - the whole point of frequent iterations is to maximize feedback that the team can then act on to correct/improve their work. QA has pretty important feedback. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">But to claim that a team isn't Agile unless QA is integrated with the team simply isn't true. It does require more investment into communication and does slow feedback loops, but it does not prevent the team from delivering working software on a frequent basis, nor does it prevent the team from adjusting priorities as needed.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">3. You are not INVESTing in your user stories.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">INVEST is an acronym that identifies properties of a good user story. It stands for Independent (of other stories), Negotiable (in scope to fit in a sprint), Valuable (to end user), Estimable (by team), Sized appropriately (for a sprint), Testable.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">It's a good acronym. But it assumes that the team is a) working in user stories, b) those stories are expressed in INVEST form, and c) the team is good enough at generating these stories so that the team can perform useful work on them.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">What if you're not working in user stories? There are any number of alternatives (use cases, requirements documents, etc) that seem to work just fine for many teams. Sadly, the author misses a golden opportunity to sell the ultimate cross-functional team solution - having the customer as part of the team itself. User stories are a record of a conversation (usually between the customer and product oriented roles). If all of the roles (dev, QA, etc.) are right there for that conversation it is less important to have a detailed record of the conversation, especially if the customer is ON the team and can re-engage in that conversation as needed.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">4. Tasks are assigned to team members by a manager</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Blog: "In a truly agile team, each member can pick which tasks he or she will work on next, as long as it pertains to the next most valuable user story.". </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Yes, some teams do indeed work this way, assuming that the team members have a good understanding of what the "next most valuable" story is. Not all teams work this way. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Many highly agile teams trust their project and product managers to do their job and properly queue up work for the team. Why did they trust the product and project management to queue work properly? Because they were directly involved in the requirements gathering and prioritization activity as it happened and were part of the decision making process.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">5.Team is told how much work to commit to</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">No argument here. If the team did not generate the estimates of work, they aren't valid, regardless of how much the stakeholders hope or expect to the contrary.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">6. You are reporting rather than discussing your progress</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">There's not one but two assumptions made here about what an agile team should be doing. The article first mentions stand-ups and then goes on to claim that the questions inherent in the format are not there for the manager to keep tabs on the team, but to elicit another team members thoughts.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Stand-ups are a communication technique. The three questions mentioned in the article are a further refinement of that technique. Stand-up meetings are actually a replacement communication technique for teams that do not have a better means of communication (e.g. osmotic). The three questions mentioned in the article are a refinement of the stand-up technique to teach teams what is important to discuss in the context of the whole team. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Don't get me wrong, I am a fan of stand-up meetings, and the same question format outlined in the article. But to claim that a team isn't agile if they aren't doing both highlights a lack of recognition that there are other equally valid communication techniques.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">7. Not focused on completing the most important user story</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">This one is too vague to dissect in detail. There is no definition on the definition of "most important" in the article, only the statement that if you don't focus on the most important task (however defined), you're not being agile. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In my experience there are many different ways to define most important - revenue, customer request, production fault, technical debt - the list goes on and on. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">At any given moment you may have several "most important" tasks to choose from to work on, depending on the stakeholder perspective you are using. If your means of selecting work ignores less visible priorities (e.g. technical debt), you run the risk of making life much harder for the team as the application ages.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">8. You changed to agile last year, and haven't changed a thing since</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">No argument here, especially considering the condition set up by the sign is a team new to agile. Teams that have been doing agile for some time may go for long periods without significant changes to their process, but adjustments to process for novice teams are critical to long term success. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">9. You are not ready to release on time with an incomplete scope</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Overall, I agree with the author on this issue as well. In the article the author focuses on the value of done-done story completion and proper layering of the stories so that if the team isn't done with the current layer, they can deliver the previously completed layer and still realize business value.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">But consider this. Not all software projects are driving to a specific delivery date. Take the gaming software company Blizzard Inc - their long-standing policy has been to only deliver when they have reached a certain level of feature completion. There is nothing inherently un-agile about basing your release on feature completion as opposed to a specific date as long as your team is aware and managing the trade-offs this approach presents.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">10. You are not getting customer feedback every sprint.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">This one is a bit misleading. My expectation on reading the sign was that the importance of frequent customer feedback (e.g. every sprint) was the key. But the author's explanation focuses on whether the team incorporates feedback from the demo into the upcoming sprint. If not, you're not agile.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Regarding the assertion that you are not agile if you are not incorporating that feedback into what you are building I'm in total agreement. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I think that the point would could have been better reinforced if the explanation focused on the value of feedback from actual customers. Customer feedback is the single most important feedback loop there is. If you aren't getting direct feedback from the people (institutions, whatever) you expect to buy your product, how do you know if you are building the right thing? Don't assume that your customer research teams or marketing group are an adequate proxy for your customers - find a way to get real customers a room with the team and watch them use the software.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In closing as strange as it looks from the dissection above, I appreciate the fact that the author posted this article. Obviously we disagree considerably on what the boundaries of agile is, but without postings like his we miss the opportunity for dialog on what exactly this agile thing is that we are so passionate about is.</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com1tag:blogger.com,1999:blog-2123916488544905831.post-40482422999677894342012-02-17T13:51:00.000-08:002012-02-17T13:51:35.765-08:00Picturing cultural changeIn a significant departure from my typically over-verbose style, I'm doing a quick vignette today on an interaction I saw occur with one of the teams that I am currently working with on their transition to Agile. <div><br />
</div><div>The backstory on this is that one of the persistent pains for this team is a disconnect with QA, so the team agreed to shift their working pattern (culture) to incorporate QA as a direct part of the team, with a much more prevalent role related to work in the current iteration. </div><div><br />
</div><div>What the team knew was that this should give them much shorter feedback loops on if something needed to be fixed or not, and it should also greatly shorten the amount of time that the project would go dark in QA at the end of an iteration/release.</div><div><br />
</div><div>What teams experienced with multiple roles working together know about this closer collaboration is the fact that when you have close association with the work that a specific role is doing on a day to day basis, you learn about that role to the point where you naturally take on some of their work.</div><div><br />
</div><div>Rather than trying to communicate to the team every single advantage to having all of the roles working together closely, I kept the focus on the direct pain the team was trying to address. I knew that sooner or later the secondary effect of role "spreading" would happen, but not when.</div><div><br />
</div><div>The following picture is a screen shot of a conversation that took place between one of the UX designers on the project (Val G) and one of the developers on the project (Thomas H). I was impressed enough at how fast the team shifted their culture to realize this secondary benefit of close collaboration that I thought it warranted a blogging. </div><div><br />
</div><div>Here's the conversation:</div><div><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLBCAWUZJ8d5H1EEuX-GtQM1DNJsSJM-Fkf5P_BquTCM6icV_H_4TM2kdmPM8_dIcKisgCkBloWX9AGOzFMmTBJtKRR8uEJDxbfUvKcJQM6rzANDiBn564L-dFHhfXqP-Pta9yAJrLw7A/s1600/QA+Cultural+Shift.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLBCAWUZJ8d5H1EEuX-GtQM1DNJsSJM-Fkf5P_BquTCM6icV_H_4TM2kdmPM8_dIcKisgCkBloWX9AGOzFMmTBJtKRR8uEJDxbfUvKcJQM6rzANDiBn564L-dFHhfXqP-Pta9yAJrLw7A/s1600/QA+Cultural+Shift.jpg" /></a></div><div><br />
</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-51499868433924787262012-02-03T15:13:00.000-08:002012-02-03T15:13:01.342-08:00A Tale of Two Burn Charts<div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Within the last month we've launched two teams at Walmart Labs using methodology tuning as our means of incrementally introducing Agile. The new "process" introduced for each team was more or less the same:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">1) Team will work in iterations</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">2) Team will create tasks from the user stories allocated to the iteration, and provide work estimates for tasks based on a simple time scale - 2 hours, 4 hours, 1 day. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">4) Tasks are defined as "done" when code/assets/other is checked in and any acceptance criteria for the task has been validated. Iteration is "done" when the working code is deployed to stakeholders and QA has signed off on all tasks/stories within the iteration.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">5) QA will work directly with the team, recording and completing their tasks in the same manner as the rest of the team in addition to acceptance evaluation as needed on other tasks.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">A few differences of note between the teams: </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">1) Team A opted to try out 3 week iterations, Team B went for 2</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">2) Team A had an initial training session on iteration planning separate from the actual iteration planning exercise, Team B had training (hastily) incorporated into the iteration planning.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">3) Team A was primarily on-site, Team B was widely distributed.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">For each team the source of the stories for the iteration were derived from existing sources, namely feature lists not articulated in typical story form. This was not an oversight, the teams did not have shared experience in working with Agile style stories, so rather than impose additional training burden on them we collectively agreed to work with the existing resources and revisit the story issue at the next reflection session.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">One of the specific "pains" that the overall group was suffering was a lack of visibility into what was happening in the midst of development. This manifest itself in predictable ways - release schedule slips, lack of stakeholder knowledge of feature changes, etc. In addition to the methodology changes that the team agreed to listed above I made it a point to generate daily burn charts on the tasks the teams were performing during the iteration.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Rather than provide a day-by-day running commentary of the iteration, let's skip to the end to see if the butler really did do it:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px; text-align: center;">Team A Task Burn Chart:</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxKvrrqLySk5Ja4Qyl8xKQsu355GuUaSVURfbPbUBqCRfx8h6ByrCzWYpBU_aNgajSkn8iUV_7s0p9e0eaphb0FyGS0XVvHgOaStYFT1T43E0a-zc3vauBKH2xtrkHSFs2s88YEru8css/s1600/Team+A+burn+chart.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="295" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxKvrrqLySk5Ja4Qyl8xKQsu355GuUaSVURfbPbUBqCRfx8h6ByrCzWYpBU_aNgajSkn8iUV_7s0p9e0eaphb0FyGS0XVvHgOaStYFT1T43E0a-zc3vauBKH2xtrkHSFs2s88YEru8css/s400/Team+A+burn+chart.png" width="400" /></a></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px; text-align: center;"><i>Red line denotes ideal burn rate for the iteration</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px; text-align: center;"><i>Green line denotes actual team completion of tasks</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px; text-align: center;"><i>Blue line on bottom of graph denotes new tasks introduced during the iteration</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px; text-align: center;">Team B Task Burn Chart:</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgykqQb5Z6KKSGIk0MOsByatR_gJZwZfHW5PhnJzLm26YLsRbHbSkGBzw8JJiMr5Fzpy1xDjti-W9uUiQe463tpgIUy8xZ3w6sk2GB2lHzEpL9H5BqWa6R8rVVUb843AGyip6UOEGeOOKA/s1600/Team+B+Burn+Chart.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="296" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgykqQb5Z6KKSGIk0MOsByatR_gJZwZfHW5PhnJzLm26YLsRbHbSkGBzw8JJiMr5Fzpy1xDjti-W9uUiQe463tpgIUy8xZ3w6sk2GB2lHzEpL9H5BqWa6R8rVVUb843AGyip6UOEGeOOKA/s400/Team+B+Burn+Chart.png" width="400" /></a></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px; text-align: center;"><i>Red line denotes ideal burn rate for the iteration</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px; text-align: center;"><i>Green line denotes actual team completion of tasks</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px; text-align: center;"><i>Blue line on bottom of graph denotes new tasks introduced during the iteration</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Based on the burn charts alone, guess which team had delivered working software at the end of their iteration. Go ahead - I'll give you a minute to make your guess.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">...</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Ready? It was neither. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Surprised? Don't be. Burn charts are a tool to understand what is happening during the course of an iteration, not a predictor of success. Even with experienced teams that have a track record of successful delivery each iteration it is entirely possible to fail to deliver at the end of an iteration. For teams that are using burn charts for the first time the burn charts serve only one useful purpose, which is to raise awareness to the team on what sort of underlying problems a burn chart can indicate once a team has some history of delivering in iterations.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Let's take a little walking tour of what occurred during each iteration for the two teams:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Stop #1 (Team A and B)</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Note that early in the iteration both teams discovered a number of tasks not previously captured. For Team A, it was 5 new tasks, Team B added 12. Considering that the purpose of the iteration is to provide a period of focus for the team by not allowing changes to the work during that time, adding new tasks certainly seems to indicate that new features showed up during the iteration. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">What actually happened was that both teams realized that there were tasks that were missing from the stories that they had agreed to deliver and as a result they added the new tasks to the iteration without realizing that they had invalidated their earlier work estimates for the iteration and increased risk that they would not deliver on time.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Stop #2 (Team B)</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">After an initial addition of 12 tasks Team B continued adding tasks along the way, peaking up to 4 new tasks in a day twice. What is interesting about this influx of new tasks is that the team didn't detect this problem until it showed up in the burn chart, even though they had already diagnosed it in the initial "methodology building" reflection session. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Stop #3 (Team B)</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Notice that throughout the burn chart there were only three days where the number of net tasks declined. A casual observer might interpret this as "the team isn't doing anything", but that wasn't the case here. Two factors were behind this seeming lack of progress. First, the lead developer (who had taken primary responsibility for managing task state within the tracking tool) was on vacation for a week. In his absence the rest of the team continued to get work done, but didn't update their progress in the tracking tool.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Stop #4 (Team A)</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">If you look close to the end of the burn chart for Team A, you'll notice a small spike in new tasks two days before the end of the iteration. In this case the tasks in question were not likely to cause a delay in the completion of the iteration but they did represent a lack of understanding of the importance of focus during the iteration. Much like Team B on Stop #2, Team A had not yet developed an aversion to changing work during the iteration.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Stop #5 (Team A)</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Look at the end of the burn chart. Notice how it concludes with 4 tasks remaining open? In this case this wasn't a reporting oversight, there were 4 actual tasks that were not completed at the end of the iteration. All 4 of these tasks were work needing to be performed by QA. It would be easy to claim that QA lags behind development and accept that the iteration is complete, but one of the rules of our newly minted methodology was that QA would be performing their work alongside the other team roles, not trailing it. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">End of Tour</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Even though there was a huge disparity in the perceived progress of the two teams, the reality is that both teams finished the development work more or less on time. Team A had less overall work remaining to complete their iteration because of a closer communication between Dev and QA. Team B had more work to complete the iteration because QA was not as aware of progress and started their work later. Team B also had to spend time correlating completed tasks with their relevant stories (OK, feature lists) to communicate to stakeholders what user-centric functionality had been completed in the iteration.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">The moral of our story is that neither team failed - both executed against their tasks rather well, at least from the development perspective. Visibility definitely improved, as did concrete visibility for both teams of previously hidden inefficiencies (effect of late QA involvement, lack of visibility of progress). Did the achieve total success in all of their corrective actions? No, nor was there ever an expectation that they should. The teams did learn something useful from the changes in their work and have already applied this knowledge to their current iterations of work to continue the process of improvement.</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-32571627459168566782012-01-16T20:20:00.000-08:002012-01-16T20:20:45.517-08:00Crystal Base Jumping<div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I've just returned from the <a href="http://www.skydivemesquite.com/home/45-skydivemesquiteboogies/59-blue-skies-boogie">Blue Skies Boogie</a>, an annual skydiving event that happens every January in Mesquite, NV. For the non-skydivers out there, think of a "boogie" in the same terms as a really cool software conference, with gravity as the keynote speaker.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">As is my wont, I spent some time pondering the metaphoric similarities between my chosen passions - in this case software development and skydiving. it reminded me of a topic I had intended on writing on a couple of years ago but never got around to doing until now.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Several months ago I picked up a book on <a href="http://en.wikipedia.org/wiki/BASE_jumping">BASE Jumping</a> - the extreme sport of jumping off of anything that isn't actually flying around in the air and living to tell the tale. Since I'm already an avid skydiver, BASE jumping seemed a pretty natural next step in my nonstop quest to torture my poor worried mother half to death (at least that's how she puts it).</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">BASE (Building, Antenna, Span, Earth) jumping is to skydiving as skydiving is to climbing down a ladder. Sure, both will do the job of getting you down to the ground, but there's a world of difference in the ride.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">A skydive is driven by a simple metric, altitude. At specific altitudes there are actions that must be taken in order to you to survive a skydive, let alone land unharmed. The penalty for failing to perform these actions quickly and decisively is as steep as it gets.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">BASE jumping is no different in that it is ruled by the same altitude metric. It also requires actions that must be taken in order to survive. What makes the critical difference between the two is the time scale in which these actions must be performed. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">On a typical skydive you may have up to a minute of freefall time before you reach the altitude where you must deploy your parachute. For a BASE jump, 7 or 8 seconds is about the maximum amount of time you get. Not a whole lot of room for dilly-dallying, if you know what I mean.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I know, I know. I promised that this post would have something to do with software development. I promise we're getting there.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">A few years ago a company I was working for was entertaining the leadership of an important medical society. We had previously been discussing the possibility of licensing of some of our medical content to them for an educational application under development for them by a third party. We were all under the impression that the purpose of the meeting was to close a content licensing deal, and were quite surprised to hear the representative from this society apologize to us because even after a year of development their educational application was not going to be delivered in time, thus eliminating the need for our content.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">During a break in the conversation one of my peers said "What if we went ahead and built it for them? We seem to be pretty good at this web application stuff, right?". It was one of those perfect questions - the kind when you can just feel the world around you come into focus a little brighter and sharper than it was before.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">The only catch was that the application had to be ready in time for a July launch, which at the time of this meeting was less than 3 months away. Now before you start thinking to yourself "This guy is a real glutton for punishment!", may I remind you to take a moment to review the name of this blog? Are you really shocked to hear that I've pointed said Agile Sadism at myself from time to time?</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Anyway, it took us a little over a month to work out the contractual details of the project, leaving us with a grand total of 7 weeks left to build and deliver a working application.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">OK, this is the clever bit where I tie our analogy into the story. Recall the relative metrics for skydives versus BASE jumps? If the previous team "cratered" their project after a year, how could we possibly think that we could nail our BASE jump after only 7 weeks?</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i>Editor's note: The term "cratered" is a skydiving term used to indicate a landing where the skydiver failed to deploy a parachute. The management of this blog does not endorse this as an effective method of completing a skydive, even if you like to make a big entrance.</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Successfully transitioning a methodology from a more "normal" delivery period isn't any more of an accident than successfully transitioning from skydiving to BASE jumping. Fortunately for us, Alistair Cockburn's <a href="http://en.wikipedia.org/wiki/Crystal_Clear_(software_development)">Crystal</a> provided a meticulously detailed plan for our Crystal Base Jump. Although we may be straining the limits of what text can be posted in a single blog entry, I think it is important enough to post it here in it's entirety for the sake of others facing similar extreme projects. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Here it is:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><b>Put smart, experienced people in a room and get out of their way.</b></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">That's it.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Actually, that's not it. Our success was predicated by the choice of the people that were in the room. Although my claim to intelligence and expertise is questionable, my primary teammate [Nate Jones] certainly knew what he was doing.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">What was most interesting wasn't how we were working, it was the rate at which we'd adapt how we were working. Our "methodology" could literally change within the space of a few hours depending on the current circumstances of the project. It is my belief that what really made the difference for us beyond our ability to deliver software is that we shared a common domain language for our methodology, allowing us to shift process with minimal signaling - usually just naming a technique would do the trick.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I know, you read all the way down here, thinking that there'd be all sorts of information on how to do your own "Crystal Base Jump" imparted. I don't want to leave you completely empty handed, so I'll close with a quick discussion of some of the key techniques we used to help achieve success. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><b>Customer Negation</b> - We all have deep familiarity with the term "The customer is always right". Well, this isn't the case in a Crystal Base Jump. It's not that they are wrong, it was simply because we couldn't afford to commit any time to cycling on customer feedback. At the outset of the effort we identified their "without which, not" features that had to be delivered, and spent some time understanding the amount of play we had with the implementation of those features. Once we had clarity on these features we literally went dark on the customer for the remainder of the development period. The next time they saw anything related to the application was a day or two before we went live with the application. This practice of "customer negation" was actually spelled out in the legal contract</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><b>Trim the Tail</b> - I first heard about this technique from <a href="http://www.linkedin.com/pub/jeff-patton/0/466/9">Jeff Patton</a>, who I am sure will correct me if I am improperly identifying him as the originator of the technique. Traditionally coders have a tendency to consider a given feature or set of features as an "all or none" proposition - either they are delivered at a specific level of fidelity or they aren't considered "done". </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In Trim the Tail you look at feature implementation as more of a staged effort. Initial delivery of the feature would be at the ["Yugo"] level: it gets the job done, but ain't pretty. Subsequent work in the same feature area would enhance the feature(s) to the intended level of completion. In the case of our Crystal Base Jump project, not only did we have a number of user-centric features delivered in a minimal state, some elements of our technology stack were also Yugos at delivery time.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><b>Walking Skeleton</b> - If Trim the Tail is a tactical tool, Walking Skeleton is the strategic. Also learned from Jeff Patton, this practice focuses on the implementation of a minimalist set of working features across the breadth (all major functional areas of the application) and depth (all layers of the technology stack). </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Use of the Walking Skeleton technique gives you early visibility into the complexity of implementing the full feature set as well as early experience in how stable the technology stack is for the application. Walking Skeleton is a great insurance policy against schedule devouring features and late discovery of technology stack instability.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><b>Customer Proxying</b> - Customer Proxying comes into play in situations where for whatever reason the team does not have easy or frequent access to actual customers. In our case the lack of customer access was quite intentional, but it didn't mean that we didn't care about what was important to them. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In our case team members had considerable experience with thinking in terms of customer Personas and were able to channel these personas as needed during the development process.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><b>Incremental UI</b> - Although this technique is in theory a natural extension of Trim the Tail / Walking Skeleton, it does bear mentioning because of the specific positive impact it had on our project. Introduced by <a href="http://www.linkedin.com/in/natemjones">Nate Jones</a>, this technique is the most elegant incremental delivery of UI fidelity I've ever seen. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">It goes something like this.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">1. Paper prototyping to confirm basic user story fulfillment</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">2. Clickable prototypes to confirm navigation and user story details</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">3. Incremental integration of application stack against clickable prototypes with low fidelity UI formatting</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">4. Pretty pixel UI formatting and UI finalization</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">The advantage of the technique was that from the very start we had a consistent walkthrough across the user interface that was the basis for easily demonstrating application development progress. This incremental delivery kept the UI and application stack development highly cohesive while allowing each to proceed more or less independently of each other.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">To be sure, there were other techniques and tools we used in the course of our Crystal Base Jump, but these were the ones that stood out the most during the heat of battle. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Final thoughts on Crystal Base Jumping. Don't do it. Seriously. Much like the real thing, you'll fail unless you have the right experience, skills, and team. Unlike the real thing, the price you'll pay for failure isn't death, but a failed project after such a Herculean effort is going to hurt. A lot.</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-2419554446767801802012-01-02T15:40:00.000-08:002012-01-02T15:43:08.375-08:00Fixing New Years Resolutions with Agile<div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">December 31st, 2011. 11:25PM MST: </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">For what seemed to be the 17 millionth time I was asked about my New Year's resolutions for 2012. Before I could summon up the energy for yet another foaming-at-the-mouth diatribe against the futility of this custom I realized that my mouth-foaming was sounding suspiciously familiar.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">It's an exceedingly rare occurrence when you actually listen to your own rant. Was it the champagne that had elevated my consciousness to this rarified state? Or perhaps it was the euphoria of observing all of the lovely ladies in attendance at this party that had perfected the art and science of the "little black dress"? Whatever it was, it was working.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Here's what I heard when I actually started paying attention to my little rant:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">A) New Years resolutions almost always fail</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">B) Why only make these life-altering changes once a year?</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">C) Even if you do make progress towards a resolution it is considered a failure if total success isn't achieved.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">D) Resolutions are a conspiracy perpetrated by the fitness and weight loss military-industrial complex, which channels the funds gained from the brainwashed "Resolutionist" masses into advertising for fast food and big screen TV's, which in turn subvert yet more of the masses into their nefarious vicious consumerism cycle.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">OK. I made that last one up. I really have to find a way to turn the channel when one of the cable stations plays a "Conspiracy Theory" movie marathon late at night</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Anyway, if you look at the first three points, they seem awfully familiar to anyone that has been on big software projects, don't they? Let's take a closer look:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">1) New Year's resolutions almost always fail = Big <i>(as in budget and/or time to delivery)</i> software projects almost always fail</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">2) Why only make these life-altering changes once a year = Why limit releases to once a year or so?</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">3) Progress towards a resolution is forgotten if the full resolution isn't achieved = New features/improvements implemented early sit unused until the whole release is delivered</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">The epiphany for me isn't some new insight into the software business (I'm sure some of the repeat visitors here would be shocked if I <b>ever</b> come up with some new insight into the software business).</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">No, the epiphany is in how we deal with our New Year's resolutions. Forget this dysfunctional "all or nothing" tradition we keep torturing ourselves with. Let's take a hint from the software business and do our New Years resolutions the Agile way.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Since we're talking about a team size of one, we can really strip Agile down to bare metal:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">1) Iterate/deliver frequently</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">2) Reflect and adjust</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Let's test this out. Say that under the old repressive regime of "Yearly Resolutions" I'd set a big goal for myself - such as learning how to become an Ultimate Pickup Artist (UPA). Although there is a strong romantic appeal to throwing myself into such a noble goal with abandon, what I'm really interested in is results. After all, what if I'm really not cut out to be an ultra-babe magnet?</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">With an Agile approach to my New Year's resolution of becoming an UPA, I now have an extensive toolbox of techniques and practices to bring to bear. One of the first I'd reach for is a little gem called "fail fast". </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In this case, fail fast means two things. First, can I bear uttering inane pickup lines with a straight and sincere facial expression? Second, do I have what it takes to endure the wrath of women offended by lewd suggestions in pursuit of the small percentage that are either over-medicated or have otherwise taken leave of their senses to the point where they'd be smitten with a tawdry pickup line?</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Right there is more than enough work for a first iteration. Assuming monthly iterations, the theme for January would be to "fail fast" and my work product would be to practice my pickup line delivery and insensitivity to criticism and/or physical assault. Heck, with a bit of careful planning I may even be able to work towards both goals at the same time.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">By the end of January I'd have ample data to reflect on whether I'm socially and morally corrupt enough to be a truly stellar UPA. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">If it seems I have what it takes, I'd be ready to take my next incremental steps in February towards my goal.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"> If not, I'll take comfort in the fact that I didn't waste a lot of time and energy in finding out that contrary to appearances, I do have some vestige of a conscience lurking somewhere and can instead focus on pursuing a more appropriate personal resolution, such as honing my gender sensitivity skills.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In conclusion, although you may not agree with my choice of resolutions, you can't argue with success. If you really want to make those New Year's resolutions permanent, you gotta go Agile!</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i>Editor's note: No actual females were harmed during the manufacturing of this blog entry. Our brave volunteer test reader (<a href="http://www.ghennipher.net/about/">Ghennipher Weeks</a>) did suffer some emotional trauma in the line of duty, but with just a few short months of intensive therapy, she should be just fine.</i></div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com2tag:blogger.com,1999:blog-2123916488544905831.post-71953284552195504572011-12-21T21:26:00.000-08:002011-12-21T21:26:06.957-08:00You can tune a methodology, but you can't tuna fish (tune a fish)<div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Last week was our first pass at introducing a new methodology to the client teams. Prior to our rollout there was significant concern throughout the group that we were going to impose so much new process that innovation and creativity would be stifled.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I was a bit surprised by this, not only because I had been constant in my verbal commitment to the team that we would only implement just enough process to keep the whole team working and productive, but also because I figured by now they'd have seen glimpses of my deep and abiding loathing for any activity that isn't directly related to delivering quality software. If nothing else, I'd have hoped that they would have noticed my highly refined sense of laziness when it comes to doing things not directly related to delivering working software.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">But I digress.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In talking with the team I heard stories about a previous attempt to install Scrum as a working methodology for the team. It wasn't successful. This lack of success wasn't because of any fundamental flaw in Scrum, it was because the previous implementer didn't recognize that there was a working methodology in place and tried to impose new process where things were already working, and failed to recognize where the existing process could use some shoring up. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">What may have made a difference for our former Scrum Master was a realization that there is no such thing as a singular "correct" methodology. For every team delivering software there are nuances to the team, their environment and their problem domain that require some level of "tuning" to get their chosen methodology working just right for the team. Since I'm eager to get to the details of our "build-a-methodology" activity, I'll save my "Agile certifications only prove someone can keep their butt in a chair for three days" rant for another time.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Knowing that the team had a failed methodology adoption under their belts (not to mention the attendant "methodology is bad" jitters), a different approach seemed to be the best course of action.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">As luck would have it, I had just the thing sitting in my toolbox.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In the book "Agile Software Development" (Cockburn, 2007), Alistair describes a technique for methodology tuning. I don't want to spoil the ending for you (no, it wasn't the butler), but here are the highlights of the technique in bullet form:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Examine one example of each work product</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Request a short history of the project to date</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Ask what should be changed next time</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Ask what should be repeated</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Identify priorities</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Look for any holes</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Currently we have 5 distinct teams working in the Mobile group at Walmart Labs. 4 teams are focused on client applications (iPhone, iPad, Android, Mobile Web) and a services team that provides functional API's to the client teams. No singular methodology is going to work for all of these teams, even if we ignore the fact that most of the teams are distributed and are working within the machinery of the larger organization (no, we really didn't ignore those factors).</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Methodology tuning is deceptive in that it seems to be a relatively straight-forward activity. Steps 1 through 5 are easily performed by anyone with a heartbeat and rudimentary conversational skills (e.g. upper management). Step 6? Well, that's kinda the secret sauce - the step that moves this activity from a <a href="http://alistair.cockburn.us/Shu+Ha+Ri">"Shu"</a> level interaction all the way up the scale to the <a href="http://alistair.cockburn.us/Shu+Ha+Ri">"Ri"</a> level.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Let's take the "should change" elements from our exercise as an illustration. Here's the list of things that the team identified as being painful and worth avoiding:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Different roles (QA, Dev, UXD) did not interact well</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Business drove scope creep</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Requirements not clearly stated and in some cases showed up late</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Lack of visibility into development progress</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Confusion around roles and responsibilities</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Key activities missed</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">* Design changes close to release</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Out of this list two major patterns emerge. First, the team was not prepared for late changes and/or requirement creep. Second, there was a considerable amount of confusion over who was responsible for what and visibility into overall progress towards delivery. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">A novice methodologist looking over this list may conclude the following:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">1) Requirements need to be more clearly stated and should not be allowed to change beyond a certain point in the development process. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">2) A clear statement of roles and responsibilities needs to be created for the team.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">3) Team members need to report more clearly their current status and progress on their work.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">All of the above changes seem to address the "holes" as surfaced by the discussion with the team, but each proposed change either imposes more work on the team or reduces their ability to change their mind about what work should be done.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Contrast that with the proposed changes I worked out with the team:</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">1) Any task performed by the team cannot exceed 1 day of effort to complete. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i>By reducing the maximum size of tasks that the team can perform to a single day it creates a natural tension on the product team to spend more time on the requirements, both in decomposition (smaller stories = easier to estimate tasks) and in simply thinking more about the details of what the requirements should be (more thinking = less likely for late surprises. It also influence scope creep by exposing the cost of "that little extra" being slipped in by the business)</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">2) During release planning the stakeholders will use risk analysis as part of organizing the work of the team. </div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i>The most common source of significant changes late in the development process for a product is responding to bad news. By identifying the features in an application that have the highest "risk" (<a href="http://agilesadist.blogspot.com/2011/09/stories-from-knowledge-acquisition.html">Risk Reduction</a>) we can organize work in such a way that bad news (if it shows up) is delivered early, giving the team more time to come up with a plan "B".</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">3) No iteration may have more than 50% of it's work be "must have" features</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i>Setting this rule on iteration planning has two purposes. First, it again puts pressure on the stakeholders to be clear about what "must" be delivered versus what can be cut if the team runs into difficulty, reducing the chance of scope creep showing up late (scope creep is almost always accompanied with claims of "we have to have this, can't ship without it"). </i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i></i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i>Second, having this "50%" buffer in place does allow for mid-iteration course corrections. It's not a recommended approach in that it violates the "focus" principle but is a useful tool for teams still working on building trust with the stakeholders that they can course-correct as much as they see fit after the current iteration.</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">4) Tasks, iterations and releases all must have clearly defined rules of what "done" means.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><i>Having clear rules about what it means to be done with a task, an iteration, or even the release greatly facilitates the process of providing visibility into the current status of a development effort. It also goes a long way towards solving the problem of different roles not interacting effectively because in almost every case part of the definition of "done" for tasks and even iterations involves direct interaction between different roles on the project. For example, in our project an iteration isn't done until two things happen - QA approves the work performed in the release, and the product of the current iteration is delivered directly to stakeholders.</i></div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Contrary to appearances, the point of this compare and contrast exercise isn't to strut my agile plumage. Take any 5 agile gurus, and they'll have at least 10 different opinions about how best to address the pains of the team, 20 if you let them iterate.</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;"><br />
</div><div style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">The real point was to illustrate the value of having a methodology tuning tool in your agile toolbox. As stated previously, no two products and/or teams will ever be the same, why would we expect our methodology to be any different?</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com3tag:blogger.com,1999:blog-2123916488544905831.post-10288653636591597112011-12-05T15:00:00.000-08:002011-12-05T15:00:32.007-08:00Team building: Recruiting life in the Big City<span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">As part of my new responsibilities with the mobile division of Walmart Labs, I am working directly with our in-house recruiter on finding talented candidates to join our group. As recruitment for our group had started well in advance of my joining the team, my first task was to sort through a relatively hefty pile of resumes to find promising candidates for a number of different roles within our team.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">It wasn't long before I had two piles in front of me (figuratively speaking, no actual tree-killing stacks were made). The first pile, containing the vast majority of the resumes I had reviewed, were the rejects. The second, a meager stack at best, were the candidates interesting enough to warrant an actual conversation.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In reflecting on the two stacks, I couldn't help but apply a mental label to each. The first pile (by now leaning precariously over the trash icon on my desktop) became the "Cogs". The second were the "Players".</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Cogs (to my mind) are the people in the software business that are there to do a job, draw a paycheck, and that's about the extent of it. Their resumes were an exercise in HR pre-screening hurdle jumping, and very little else. Of course it is entirely possible that there was much more to these candidates but if so it certainly didn't shine through.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">In contrast to the Cogs, the Players (think sports, not some guy in a red velvet smoking jacket) deliver. They are craftspersons, always working to improve their skills. They were engaged with their professional community. And they made a difference where they had worked.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Frankly, I was rather surprised that I had a pile of Players in the first place. Silicon Valley is an extremely competitive market for talented individuals, and large companies that don't have a reputation for technical excellence tend to not attract these sort of candidates.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">So I set off to find our team's recruiter to find out how these interesting resumes had snuck in. I had been looking forward to this conversation because the recruiter in question had handled my recruitment, and I was interested in hearing her opinion of what it was like to bring in someone like myself to the team. For the record, no, I wasn't that bad, but I definitely did not follow the game plan on my way in.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Talking with Kathleen as her "customer" was a very different experience than as her recruit. I learned very quickly that her path to the company was similar to mine - she too had been pursued by a colleague and wasn't exactly overwhelmed about the opportunity. In talking about the recruiting and onboarding process it was clear that her level of frustration in dealing with the hiring process was even greater than mine. I had only been through it once, whereas this was her day to day reality.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Our first task was to adjust the screening process so that the candidates coming in were better qualified for the team that we are building. More players, less cogs. At first I thought that this would be as simple as changing the job descriptions to better reflect what we were doing, so I stated it as I saw it: "We are creating a true entrepreneurial space within a larger company that will be a showcase for how agile teams can deliver without becoming mired in process and red tape."</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I could immediately tell by the amused/pitying look on Kathleen's face that I had said something wrong. With a shake of her head she said to me "You do know that every single large company that is competing for talent out here says that exact same thing?". As soon as she said it, I realized how naive I had been in my thinking. Of course companies competing for a limited pool of technical resources would craft the most appealing message to get the attention of the community, regardless of the reality of how the company really worked.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I had already known that recruiting for our team was going to be challenging. Much like the initial resistance felt by Kathleen and myself, the very first obstacle we would have to overcome with the type of players we were looking for was the fact that Walmart hasn't exactly been on the short list of bleeding edge mobile technology adopters. But this newest revelation made it clear that we were going to have to come up with something a bit better than a dazzlingly worded job description.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Fortunately, we do have something a bit better. Us.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">More specifically, our connection to our respective communities and other players we have worked with in the past.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">let's assume for a moment that I am a representative example of the type of player we're looking for. Yeah, I know - I'm as surprised as you that I can say that with a straight face, but just work with me for a minute, will ya?</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Had I seen a posting for my current position somewhere on the intar-webs, I would have spotted the corporate logo out of the corner of my eye and moved right along. This isn't an indictment of my current employer - you can't argue with success, and Walmart is as successful as you can get. But there was nothing interesting in that space for me, namely because the place that I prefer to work is a place where my contribution to the success of the organization goes beyond a few percentage points on a graph somewhere. I (much like other players) want to have a visible and lasting impact on the organization we are working with.</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">I now know that the space for this sort of contribution does exist because I the people that reached out to me to join the company are from the same mold and have created a space that will allow players to do what they do best. It was this personal contact by people I knew and respected that shifted my perspective on the job from "part of the machinery" to "being part of changing the game".</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Moving forward the key to success in our recruiting efforts will be this same sort of outreach to our respective communities. We will know right away when it is working by the number of times we hear in the interviewing process comments like "I applied for the position because I heard about what your team is doing and I want to be a part of it.".</span><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><br style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;" /><span class="Apple-style-span" style="background-color: rgba(255, 255, 255, 0.917969); color: #222222; font-family: arial, sans-serif; font-size: 13px;">Now that I think about it, we are already starting to hear that now.</span>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com1tag:blogger.com,1999:blog-2123916488544905831.post-16090298008948613712011-11-09T21:47:00.000-08:002011-11-09T21:47:09.345-08:00Jammin'<div class="p1">Last night I had the pleasure of participating in a "Jazz Dialog" event conceived and hosted by Alistair Cockburn. For those that are having a hard time seeing what those two things have to do with each other, I'll attempt to 'splain.</div><div class="p2"><br />
</div><div class="p1">One of the key principles of Jazz music is the element of improvisation. No two recitations of a song played by the same players will be exactly the same because the players are not just engaged in playing the song, they are also engaged in playing with each other. It is this element of improvisation that keeps Jazz music fresh and interesting for players and listeners alike.</div><div class="p2"><br />
</div><div class="p1">Imagine that you are in the audience of an impromptu Jazz jam session that has the likes of Miles Davis or Dizzy Gillespie sitting in with the group. If you are a neophyte Jazz aficionado, you may feel shifts in your emotional reaction to the music, but not really know why or how it is happening. A more seasoned Jazz fan may notice that there is some sort of interplay above or below the level of the actual music between the players, but may not be able to interpret how that interplay is affecting the evolution of the song. </div><div class="p2"><br />
</div><div class="p1">To truly understand the forces shaping the music, you'd need an expert observer who is paying attention to the players, and not the music. They would notice that Dizzy seemed a bit more subdued than usual at the outset of the song and watched Miles repeatedly challenge Dizzy to step up his energy level by intentionally magnifying his own play. Without this expert observation of the interaction of the players you may notice that the song started out slow and then picked up energy as it went on without ever realizing that it was the direct result of the interplay of the players above and below the music.</div><div class="p2"><br />
</div><div class="p1">So what does that have to do with dialog? I'm glad you asked. </div><div class="p2"><br />
</div><div class="p1">For over a decade now a group has been meeting in Salt Lake on a monthly basis to talk about software. The group was originally focused on discussing Object Oriented software development, but around the time I showed up in 2002 the charter of the group had shifted to discussion of all things Agile (and agile) related. Attendance to the group fluctuates, but there is a core group of attendees that keep coming back to sit in on these conversations. </div><div class="p2"><br />
</div><div class="p1">Why? After 10 years, you'd think we'd be all talked out. But yet we keep coming back because the monthly discussion aren't just a discussion, they are our "Jazz Dialog" jam sessions. And much like a good jam session, we can take the same old tunes (such as "estimation accuracy") which seem to be in an advanced state of expired equine violence (beating a dead… you get the point) and still getting something new out of the conversation.</div><div class="p2"><br />
</div><div class="p1">Because it isn't the topic that is important, it is the dance of the dialog.</div><div class="p2"><br />
</div><div class="p1">I had an "Aha" from the Jazz Dialog last night - it was about the implications of our roundtable "jam sessions". Three in particular stood out to me:</div><div class="p2"><br />
</div><div class="p1">1) The people that keep coming back to the roundtable sessions over the years? Dialog Jazz musicians. We all love a good jam.</div><div class="p2"><br />
</div><div class="p1">2) I believe that the people that come to the roundtable looking for answers to questions or challenges tend to not stick around because they subconsciously (or consciously) pick up on the fact that the dialog itself is more important than the outcome of individual discussions and thus look elsewhere for help.</div><div class="p2"><br />
</div><div class="p1">3) Multiple attempts to export the roundtable to other locations have failed over the years because they duplicate the format but not the musicians.</div><div class="p2"><br />
</div><div class="p1">Of course one good "aha" leads to another, so my second is that there is an inverse correlation to the amount of interest you have in a particular topic versus your ability to look past the topic to observe the flow of the dialog. I don't think I'd be satisfied with just committing to metering my engagement with a topic in order to observe the dialog, so this means that I need to practice getting better at tracking a dialog while I'm in the middle of it.</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-51964616212630819092011-11-07T08:30:00.000-08:002011-11-10T21:09:55.697-08:00The high cost of failing to introspect<div class="p1">The high cost of failing to introspect</div><div class="p2"><br />
</div><div class="p1">Disclaimer: I am not authorized to speak in any way, shape or form for Walmart, Walmart.com and Walmart Labs, the opinions expressed here in this blog are entirely my own, and if history is any sort of indicator, half-baked.</div><div class="p2"><br />
</div><div class="p1">I've been at my new position as Director of Engineering for the Mobile group within Walmart Labs for roughly 10 days now, which usually would mean that I'm barely qualified to find my way to the bathroom unaided. But since I'd like to make a good impression with my bosses I've done my best to hit the ground running as fast as I can</div><div class="p2"><br />
</div><div class="p1">Right into a brick wall, as it turns out.</div><div class="p2"><br />
</div><div class="p1">From the moment I walked in the door I was aware of a certain amount of tension between individual client application teams and a services team that was responsible for providing back end services for those client teams. Knowing that this was was the most visible area of organizational pain within my new professional home I shifted to investigative mode.</div><div class="p2"><br />
</div><div class="p1">The first theory that I tested was that there were personality and/or work ethic issues between the teams. On the surface this seemed to be a good one to start with given that the services team had been in place prior to the leadership change that brought in our "Lean Startup" oriented management and client teams.</div><div class="p2"><br />
</div><div class="p1">It didn't take long to discard this theory. When I first met with the services team their sense of frustration and anxiety over the recent changes around them was clearly evident. But what was interesting is that their passion about getting the job done was also equally evident, which means that the real problem wasn't in that room. Since I was fresh out of theories the next step was for me to sit with the team and watch them do their job.</div><div class="p2"><br />
</div><div class="p1">It worked. </div><div class="p2"><br />
</div><div class="p1">The specific job I was most interested in watching was how the team went about handling the production deployment process. As luck would have it the team was set to do a production deployment that same night. In an effort to understand what I'd be seeing during the production deployment that evening, I sat down with one of the team members and had him outline the steps in the process for me.</div><div class="p2"><br />
</div><div class="p1">An hour later we had to get another team member to come in and fill in some of the details that the first team member was unsure of. 30 minutes after that the two of them had to go get yet another guy to fill in a couple of blanks that the others didn't have enough information about. Are you starting to get the picture? </div><div class="p2"><br />
</div><div class="p1">Watching for myself it was as complex as the description. Responsibility handoffs were "over the wall" style, meaning that the person shepherding the changes through would have to start from scratch every time a new person entered into the deployment process. Scheduled event times meant little to outside teams as there was no visibility on our side as to what else was on the deployment schedule, or what was causing a deployment schedule to slip if deployments were being pushed back. Even tools created to facilitate the deployment sometimes caused more problems in the deployment than they solved.</div><div class="p2"><br />
</div><div class="p1">Translation, we were losing more than 50% of the productivity of the services team due to the "cost" of interacting with the production release process.</div><div class="p2"><br />
</div><div class="p1">What was most amazing to me was the high degree of tolerance within the larger organization of the pain of this deployment process. Now understand that I come from a much smaller team, where knowledgeable and trained people took the place of process. In a larger company we don't always have this luxury, thus the reason why the process had been created in the first place. It was clear that every single individual working within the process was working hard and doing the best they could within their specific responsibilities, but had become accustomed to the fact that this was how things worked, and it wasn't going to change. In some cases they didn't even seem to recognize this process as being "painful" from an organizational perspective. Speaking as the "Agile Sadist", I was surprised at the amount of organizational and individual professional pain that was being endured.</div><div class="p2"><br />
</div><div class="p1">You're probably thinking that my next question would be "How could this have happened?". Surprisingly, it isn't. I am sure that the actual story of how the current status quo evolved would be interesting and informative, but I believe that the actual cause is far easier to diagnose - a lack of sufficient introspection.</div><div class="p2"><br />
</div><div class="p1">Introspection allow you the opportunity to review what is and isn't working, and make changes based on that information. It is one of Alistair's core principles of the Crystal family of methodologies, and rightly so. It provides a thoughtful change agent, one that is based on first-hand knowledge and experience of the team that is performing the work.</div><div class="p2"><br />
</div><div class="p1">Without introspection there is no good measurement of whether the application of changes are needed in the first place or if they are working to address the original issue. In the case of our production release process you can discern a number of causative elements if you look closely enough, but the changes implemented to address them in most cases not only failed to solve the original issue, but actually spawned new issues by their introduction.</div><div class="p2"><br />
</div><div class="p1">Again, understand that this is not a rant against how bad production deployment seems to be at the 'ol workplace. It has certainly worked for them to this point, and allowed them to reach their business goals. But the business goals of our mobile group are different, and require a much more "agile" release capability. To be honest, it is exciting to see the possibilities for improvement here, and you can be sure that whatever we end up doing, introspection will be a key part of it.</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-67580336854747309562011-10-31T11:06:00.000-07:002011-10-31T11:06:42.348-07:00Reflecting on my career<div class="p1">It's a beautiful cloudless day, especially here at 36,000 feet. I'm on a flight headed for San Francisco and my brand new position as Director of Engineering for the Mobile division within Walmart Labs.</div><div class="p2"><br />
</div><div class="p1">When I'm not on the job one of my passions is skydiving. As you might imagine, there isn't a lot of room for reflection when you're free falling at 125 miles per hour, but since I've chosen to stay with the plane for my full flight today it seems to be a perfect moment for a retrospective on the last segment of my career with my previous employer, Amirsys Inc.</div><div class="p2"><br />
</div><div class="p1">I joined Amirsys 6 years ago, initially as the Technology Manager, then to Director of Technology and finally Chief of Technology. Amirsys was more than a job for me – it was a home, one that gave me a golden opportunity to test out a number of theories on making software development better. Thanks to my close association with Dr. Alistair Cockburn and the Salt Lake Agile Roundtable discussion group, I had no lack of theories, practices and experiences to draw from.</div><div class="p2"><br />
</div><div class="p1">One of the techniques learned from the SL Agile group that I introduced to Amirsys was a retrospective format that focuses on three key questions:</div><ol class="ol1"><li class="li1">What worked? (Things that we did that worked well)</li>
<li class="li1">What didn't? (Things that didn't work out well)</li>
<li class="li1">Try? (What are we going to do differently)</li>
</ol><div class="p1">This format worked very well for our teams at Amirsys, so I don't see any reason why I shouldn't apply it to my own career to see if I might actually learn something. </div><div class="p2"><br />
</div><div class="p1"><b><span class="Apple-style-span" style="font-size: large;">What worked:</span></b></div><div class="p2"><br />
</div><div class="p1"><b>Agile Sadism</b>. Creating and/or raising visibility on organizational “pain” was an effective tool in inducing cultural change within Amirsys, especially in the early days of adoption. Ultimately we created a team culture that was focused on rapid and repeatable delivery of value, value being defined primarily as revenue generating software. </div><div class="p1"><i><br />
</i></div><div class="p1"><i>Note to self: It's probably best not to actually tell your peers and your direct report that you are actively engaging in benign corporate sadism.</i></div><div class="p2"><br />
</div><div class="p1"><b>“Special Operations” team model</b>. Amirsys as a company had a clearly stated goal, namely to reach a specific company valuation by creating a number of complementary revenue generating “fronts”. What we didn't know early on was exactly what these fronts were going to be. Forming the development teams around a "special operations" military model of small, cross-trained teams allowed us to repurpose our output at any time based on business priorities by shifting teams and team members members to where they were needed.</div><div class="p2"><br />
</div><div class="p1"><b>Just In Time team growth</b>. Over time it was clear that our products would grow in revenue to the point where they would justify the services of dedicated team roles. Our “multiple front” business strategy made it difficult to determine when any one product would require a specific dedicated team role, rather than hire for the role on an individual product basis I introduced a “Just In Time” role growth plan across all products. When we reached a point where the lack of a dedicated role was slowing the progress of all teams we hired people capable of performing that role across multiple products. Once a role was established we would hire additional resources for that role based on overall workload.</div><div class="p2"><br />
</div><div class="p1"><b>Protecting the team</b>. I believe it was Kay Johansen that drew a picture once that has stuck with me for many years. Essentially the picture was a team surrounded by a wall called "management". The purpose of that wall was to allow in positive elements - resources, praise, etc. and block the negative elements - decision thrashing, micromanagement, unnecessary process. The not-so politically correct term for the role of a manager in this context was a "shit shield". I took that picture to heart in working with my team at Amirsys and felt I did well - our annual team member turnover was less than 10% for the 6 years I was with the company.</div><div class="p2"><br />
</div><div class="p1"><b><span class="Apple-style-span" style="font-size: large;">What didn't work well:</span></b></div><div class="p2"><br />
</div><div class="p1"><b>4 Dimensional Trick Shot</b>. Alistair Cockburn gets the credit for this term. Remember the old Disney "Flatland" cartoon that showed the peculiarities of living with different numbers of dimensions? Good. Now picture Goofy, standing in front of a four dimensional pool table. After carefully lining up his shot, he fires the cue ball right off into the middle of nothing. Three days later, when everyone has gotten bored and gone home, every ball on the table neatly drops into a pocket save one, which ends up landing directly on top of his head. Yes, that was me. Goofy, I mean - not the ball.</div><div class="p2"><br />
</div><div class="p1">Knowing that we had multiple product fronts to generate revenue on and not enough time or resources to have a dedicated platform team, I opted to have the teams build the platform as they were delivering individual products. Imagine my dismay when the CEO and my peers became frustrated with my tendency to call shots like "Enterprise wide authentication and subscription management off the side rail and into the "project that seems to be getting no resources right now" pocket Tuesday afternoon, two months from now". Lesson learned for me: No more trick shots into dimensions that the rest of the business can't see.</div><div class="p2"><br />
</div><div class="p1"><b>"Racking up Technical Debt"</b>. Early in my tenure at Amirsys the leadership of the business indicated that we had a specific time frame to increase revenue in advance of a financial event. Believing this to be the case, I decided to bias the efforts of the development team towards delivering revenue-generating products and features as opposed to clearing known technical debt. Of course what ended up happening is that factors converged to perpetually keep the date of that event 18 months or so into the future. It tok me a good three years to really recognize the situation we were in and put more effort into selling the rest of the business on clearing technical debt, by which time our technical debt had accumulated to the point where significant effort was required to clear the most pressing issues. Lesson learned: Don't trade consistent effort on clearing technical debt for squeezing out a few more features. If a specific goal requires pausing on clearing technical debt, time-box it.</div><div class="p2"><br />
</div><div class="p1"><b>What do you mean, "I don't know when we'll be done?</b>. When we finally got serious about clearing technical debt, the number one target was a nine year old application that had grown so fragile that any work within the application was at least 4X beyond when it was new. By this time we could either refactor the existing application in place, or to end all non critical support of the legacy application and kick off a brand new effort.Even though refactor in place is much more difficult than a ground-up rebuild, I chose that option to allow the business to continue to add features to the product as it was being refactored. Although I warned the business about the tradeoff between predictability in completion for ongoing feature development, when the effort spanned into several months the business became frustrated with my inability to give a hard completion date. Lesson learned for me: Tolerance for uncertainty on the part of the business as a whole is a critical part of the "Refactor or Replace" decision.</div><div class="p2"><br />
</div><div class="p1"><b>Relationships</b>. It seems strange to be discussing relationships in the context of running a software team, but ultimately I believe that this is one of my greatest failures. The key relationships that I failed to properly manage were the ones with my peers and with the CEO and President of the company, who I reported to. At the heart of my relationship failures was a lack of effective communication - about status, about progress, about challenges. I believe that this lack of transparency and collaboration on my part ultimately led to a shifting of my responsibilities that took me out of the day-to-day operations. Lesson learned for me: The team is not just my direct reports. It is also my peers and who I report to.</div><div class="p2"><br />
</div><div class="p1"><b><span class="Apple-style-span" style="font-size: large;">Try:</span></b></div><div class="p2"><br />
</div><div class="p1"><b>Sunshine, sunshine, sunshine</b>. Given that every single one of my "Didn't work" points had some element of communication and visibility involved, it is clear that I need to put more emphasis on "Sunshine" (one of the 8 principles of Crystal that discusses transparency and visibility). More specifically it is my intent to:</div><div class="p2"><br />
</div><div class="p1">1) Define clear metrics that best report progress and status to the whole team, from leadership on down</div><div class="p1">2) Create and maintain ambient data collection mechanisms that gather metrics data organically from the working teams that feed into highly visible info radiators</div><div class="p1">3) Commit to interacting with the whole team on an ongoing basis to insure clarity of meaning from the metric data</div><div class="p2"><br />
</div><div class="p1"><b>Mentoring</b>. It probably comes as no surprise that I consider myself an advanced practitioner of Agile. That being the case it is rather ironic that I haven't put much effort into encouraging the growth of others on my teams in the same subject. By putting more emphasis on mentoring in all directions (direct reports, peers, my superiors) I should be a able to multiply my effectiveness without increasing the amount of actual work I am required to do. Of course this also requires me to let go to the point where others are able to try different things, make mistakes and learn.</div><div class="p2"><br />
</div><div class="p1"><b>KISS, YAGNI, etc.</b> From an internal dialog with my ego: "Yes, I do think I am a talented software architect, and yes, I definitely want the world to know this. But do I have to prove it by setting up those 4-dimensional bank shots just to show that my secret master plan is a work of genius? Can't I just be happy with putting more emphasis on clear metrics for success and let the team decide for themselves how best to deliver based on those metrics?"</div><div class="p2"><br />
</div><div class="p1">Simply put, less focus on delivering expected value six months from now out of work being done now, and more emphasis on delivering actual value now. By setting up clear metrics for success around the work product of the teams I believe we will deliver more value now while maintaining clarity for the whole team on what we are building and how well we are performing at delivering it.</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-49019700851594522312011-09-19T11:38:00.000-07:002011-09-19T14:49:41.232-07:00Stories from the "Knowledge Acquisition" curve, part 2: Social RiskFor the three of you out there that are actually reading this blog (your check for next month is on its way), I'm continuing in the theme of knowledge acquisition stories. For those of you that didn't see the first post, you can find it <a href="http://agilesadist.blogspot.com/2011/09/stories-from-knowledge-acquisition.html">here</a>.<br />
<br />
<span class="Apple-style-span" style="background-color: white; color: #222222; line-height: 18px;"><span class="Apple-style-span" style="font-family: inherit;"></span></span><br />
<div><span class="Apple-style-span" style="font-family: inherit;">Social Risk is the focus of this installment. Seems like a strange risk to be listed as important enough to be worth devoting team resources to understanding, doesn't it? Rest assured, it does exist and in my opinion is the most prevalent cause of project delivery failures. </span></div><div><span class="Apple-style-span" style="font-family: inherit;"><br />
</span></div><div><span class="Apple-style-span" style="font-family: inherit;">We've been conditioned <a href="http://en.wikipedia.org/wiki/List_of_publications_in_computer_science#Software_engineering:_Report_of_a_conference_sponsored_by_the_NATO_Science_Committee">since the late 60's</a> to think of software development as an "engineering" discipline, complete with it's own set of laws and physics that remain inviolate regardless of circumstances. This definition works right up to the point where you run into the humans involved with the project. There's no formula for calculating the degree of political sabotage expected from a hostile stakeholder or percentage of bad code expected from an inept developer.</span></div><div><span class="Apple-style-span" style="font-family: inherit;"><br />
</span></div><div><span class="Apple-style-span" style="font-family: inherit;">One of the most important accomplishments of the Agile movement (in my humble opinion) has been the acknowledgement of humans as an integral part of the development effort. This is certainly a big step forward from the "engineering" mindset. But what hasn't quite become apparent to the adopters of Agile is the implications of humans as an integral part of the process. Simply put, humans are messy from an engineering point of view.</span><br />
<span class="Apple-style-span" style="font-family: inherit;"><br />
</span><br />
In most teams the elements of social risk are more background noise than roadblocks. Established teams doing more or less the same work that they have always done have adapted to the unique social elements in their world. But introduce change to the team (technology, personnel, stakeholders) and you now have a new social dynamic that will affect the team's ability to deliver.<br />
<br />
For new teams the social risk is much higher - everything is an unknown. Does the team work well together? Is there hidden agendas among the stakeholders? Does the team have the ability to do the work they are tasked with?<br />
<br />
Social risks can be tough to identify. It really does require a working knowledge of human psychology, something that you don't often see on the hiring requirements for development types. As with anything, experience and stories from others can help uncover these risks in your own team, so let's get to a story, shall we?<br />
<br />
Some time ago a company I worked for acquired the rights to an existing free web application that would help pathologists choose specific cellular "stains" that would allow them to identify what type of cancer cells were in a tissue sample. Our plan was to take the underlying data and build a new application from the ground up that would provide greater functionality and allow us to charge for the service.<br />
<br />
Two of the stakeholders for this project were very senior and well respected pathologists, one of whom was the creator of the application we were acquiring. As stakeholders for the new product, they had some very specific opinions about how the product should work, and worked closely with the team to make sure that the new application reflected their experience in pathology.<br />
<br />
What the team didn't realize at the time was that although our stakeholders were absolutely correct in their perspective on how a pathologist should work, it turns out that pathologists actually want to work in different ways, ways that weren't supported in the first production release of the application.<br />
<br />
The story does have a happy ending - as soon as we realized that there was significant pushback from the user community the team shifted into a weekly release cycle process and communicated extensively with the user base on progress and priorities until they had the application working to the user community's satisfaction.<br />
<br />
The team actually learned two things in retrospective. The first was that we didn't understand the motivation on the part of the stakeholders to improve how people in their field do their work. Had we recognized that sooner it would have allowed the team to translate statements like "This is how a pathologist works" into "This is how we think a pathologist should work". The second was a re-affirmation of the importance of the Crystal principle "Easy access to expert users".<br />
<br />
The moral of the story for me was that hidden stakeholder motivations were sufficiently disruptive to projects to warrant taking the time to discover and expose them to the team. This doesn't lessen the disruption - exposure of hidden motivations can be quite challenging. But the principle of "Fail Early" covers this nicely. If the warping of the project by a stakeholder(s) agenda is sufficient to ultimately cause failure, it is better to fail as early as possible.</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com2tag:blogger.com,1999:blog-2123916488544905831.post-66158494991367595752011-09-07T18:05:00.000-07:002011-09-07T18:05:58.273-07:00Stories from the "Knowledge Acquisition" curve, part 1If you've ever attended any of Alistair Cockburn's recent presentations on the nature of software "engineering", you'll have heard him discuss the early part of the design process as a game of knowledge acquisition (<a href="http://alistair.cockburn.us/Trim+the+Tail+aka+Pay+to+Learn+aka+Design+as+Knowledge+Acquisition">link </a>- scroll down to the section titled "Chapter 2 of the Story, 2010).<br />
<br />
Essentially what he is saying is that it is a successful strategy to treat initial design as a "pay to learn" period. No, you're not handing out piles of cash to trench-coated agents that are slipping you <a href="http://www.imdb.com/title/tt0086465/">unpublished USDA reports</a>. The nature of your coin is the effort of the team. What you are paying for is information about the success and/or failure of the product you are designing.<br />
<br />
Although there is no simple formula to identify exactly what nuggets of knowledge are needed to determine the success and/or failure of a product, Alistair does provide us with a map to the territory. Here are his 4 categories of knowledge worth "paying" to learn:<br />
<ol><li>Business Risk (Are we building the right thing?)</li>
<li>Social Risk (Can our team build it?)</li>
<li>Technical Risk (Will our solution work?)</li>
<li>Cost/Schedule Risk (Do we understand the cost / timing?)</li>
</ol><div>As the title implies, the point of this (and subsequent) blog entries is to tell stories about how this game of knowledge acquisition was played. Depending on where you are at in your <a href="http://alistair.cockburn.us/Shu+Ha+Ri">Shu Ha Ri</a> path you will hopefully gain something useful even if it is the certainty that yours truly isn't playing the "knowledge acquisition" game with a full deck. </div><div><br />
</div><div>This first story is about gaining knowledge about Cost/Schedule risks. At the risk of sounding boastful I've chosen to tell this story first because it was the impetus for Alistair to include the Cost/Schedule risk category to the above list.</div><div><br />
</div><div>Our story begins with the decision to create a new application that would allow medical residency physicians to study for their board examinations. Medical board examinations are typically case-centric, presenting the examinee with specific medical cases that they would then identify, diagnose and discuss treatment options.</div><div><br />
</div><div>As you might guess, the key to providing a useful learning product is having high quality content, something that Amirsys is known for within the medical community. Not only did we have existing content, but the content itself was structured in such a way that re-using existing content for new purposes (such as this learning application) is something that we are very good at.</div><div><br />
</div><div>Our skill in reuse of existing content wasn't an accident. Early on in my career with Amirsys I was surprised to discover that the timeline for the creation of high quality medical content significantly exceeded software development timelines. In other words, the most significant cost of developing a new product wasn't the development work, but the content creation for that product.</div><div><br />
</div><div>Considering that we had a pretty good idea of the costs associated with content creation, any new products requiring new content had to have a pretty convincing ROI to justify the content creation costs. Either that, or we had to come up with product ideas that wouldn't require new content creation. Thus the idea for this learning application was born.</div><div><br />
</div><div>At the time of product conception we had data from roughly 60,000 medical cases in our content repository. In order for a learning product to be successful you need to present both content to learn from and assessment about that content (questions). There was no lack of learning content, but at that time we had no authored questions over that content. </div><div><br />
</div><div>The big break came when it was pointed out that our cases were structured in such a way that it may be possible to automatically create relevant questions about the cases without requiring a medical expert to perform any authoring. On the strength of this realization the development of the product was given the green light.</div><div><br />
</div><div>Shortly after work began on the product I was participating in a conversation about an unrelated product when one of our content authors happened to mention that the cases they authored didn't have all of the content I had assumed to be required for authoring. Given how dependent we were on this content being sufficiently complete to allow for the automated generation of assessment questions, this was a significant risk to the delivery of this product.</div><div><br />
</div><div>Unfortunately there was no easy way to evaluate the suitability of the content outside of actually showing it within the context of the new product and having a medical expert interact with it. Considering that the success of the new product hinged on the fact that we didn't have to explicitly author all of these new questions we had to do something to "acquire knowledge" about the extent of this new risk.</div><div><br />
</div><div>Our solution was to build a walking skeleton of the application that would allow a user to "take a quiz". No bells and whistles - just the presentation of these auto-generated questions and the ability to select an answer and see if the answer was right or wrong. It took members of the team approximately two weeks to build this tool and put it in front of our medical experts.</div><div><br />
</div><div>Within 10 minutes it was clear that there was a significant amount of inconsistency in our case data, to the point where a paying customer would not receive a useful learning experience from the content. Armed with the knowledge that our content was not in the condition we had assumed it was, the business needed to make a decision.</div><div><br />
</div><div>Fortunately the story has a happy ending. It was determined that although our case content wasn't consistent enough to auto-generate assessment questions, it was good enough to allow us to significantly speed up the authoring process by "prepopulating" assessments that authors could then edit rather than create from scratch.</div><div><br />
</div><div>Had we not known about Alistair's pattern of "Paying for Knowledge" it is entirely possible that we would not have discovered our content challenges until it was too late to meet key delivery dates or be required to disrupt other revenue generating activities. As it turned out the product was delivered on time, with the only negative consequence being a smaller set of content shipping with the new product. </div><div><br />
</div><div>As of the time of this writing this product has been generating revenue for close to a year now and has given us the tools to build similar products for external customers who have similar expert content learning application needs.</div><div><br />
</div><div>Stay tuned for Part 2 - A tale of Social Risk</div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-8660368733868867982011-06-07T17:09:00.000-07:002011-06-07T17:09:55.206-07:00Shu Ha Ri and Distributed CognitionLast week I attended Alistair Cockburn's "Advanced Agile Master Class" here in Salt Lake. I've made no secrets about the fact that I am one of Alistair's minions, but to have me as a minion comes with a price - you have to keep me interested by challenging me to learn and grow whether I like it or not.<br />
<br />
Alistair's class didn't disappoint. I will have more to say about the class in subsequent postings, but for now I wanted to focus on a key piece of knowledge that I walked away from the class with. At the outset of the class Alistair had asked all of us to identify what we wanted out of the class. My goal was to come up with two different ideas that I could immediately put to use in my own organization. Two may not seem like a lot, but if you're around Alistair and the Salt Lake Agile Roundtable group for any length of time, you'd be amazed at how many great ideas just loiter around making a nuisance of themselves until you give in and try them and I was looking for something fresh and new.<br />
<br />
I'll save you the cliff-hanger. I had my two before the first day was out. What was interesting is how the realization of one of these two (Distributed Cognition) came about in the context of Alistair's class.<br />
<br />
Distributed Cognition (<a href="http://en.wikipedia.org/wiki/Socially_Distributed_Cognition">Wikipedia Entry</a>) implies that the common thinking about a specific domain isn't limited to an individual but is rather shared across a group interacting within that domain. Consider the defensive unit of a professional football team. In order for the defense to do their job they have to instantly react to their observations of what the offense is doing, all without relying on explicit communication between team members.<br />
<br />
When you discuss defensive units you frequently hear terms like "on the same page" or "the unit is meshing well". These terms are useful in giving some indication of how far along the team is in creating a shared cognition of their domain.<br />
<br />
Fortunately for us, business does not move at quite the same pace as professional football. But there is no doubt that business does move fast. Fast enough that "being on the same page" becomes increasingly important as the business grows beyond a few guys in a room.<br />
<br />
The reminder of the theory of Distributed Cognition was timely for me. Entering into the class one of the key challenges I had been facing (and not necessarily succeeding at) at my company was the increasingly complex challenge of keeping everyone in the company on the same page as our company grew. The tricks we used to keep everyone on the same page three years ago were failing to get the job done as we added more people, projects and responsibilities.<br />
<br />
For those of you paying attention, Distributed Cognition isn't a specific practice, like unit testing or stand-ups. It is a theory. As with any theory, there are a number of practices that are derived from it that can be applied to different situations. This is important because I wasn't looking for a specific practice - I was looking for a theory.<br />
<br />
One of the key points that Alistair kept hammering home in the class is that Advanced Agile class isn't about practices. It was about theory and self-awareness. This is all part of his <a href="http://alistair.cockburn.us/Shu+Ha+Ri">Shu-Ha-Ri</a> pattern of mastership for our software craft. For those of you too lazy to click the link, the short version is: Shu - specific practices, Ha - theory behind practices, Ri - self awareness to recognize the right theory and pick the appropriate practice.<br />
<br />
Had the class focused only on practices, we *might* have been able to learn 4-5 well enough to take away and implement elsewhere. Since we instead focused on theory and self-awareness, I now have a name for a whole set of practices that I can discover and try out to see which best suits the needs of my company. Prior to the class I was aware of the theory, but it was the environment of the class itself that fostered the moment of self-awareness that indicated the applicability of Distributed Cognition to my organizational challenges.<br />
<br />
Did everyone who was in the class get this level of understanding from the training? Good question. In some of the sidebar discussions I had with Dennis Stevens (<a href="http://www.dennisstevens.com/">Dennis's Blog</a>) it was clear that our experiences in the class were similar in regards to the understanding derived from the class, but it would be interesting to hear from others that have been in the class. If you have, please take a moment to post a comment here about your experience with Alistair's "Advanced Agile" class.Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com0tag:blogger.com,1999:blog-2123916488544905831.post-26288627802324513462011-05-10T16:48:00.000-07:002011-05-10T16:49:07.460-07:00Why isn't Agile "winning"? (part 2)<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">In Part 1 of this post I made two assertions:<br />
<ol><li>Our capitalistic business community is quick to recognize and adopt practices that have a clear impact on the bottom line.</li>
<li>That same community is not so great at adopting complex practices, and as a result settle for mimicry of the process rather than true adoption.</li>
</ol>Is this really true? Good question. In the first part of this posting we discussed a few examples of how companies failed to successfully adopt complex practices. Now let's look at an example of how a company properly declined to try to replicate a successful complex practice.<br />
<br />
In 2007 FastCompany published <a href="http://www.fastcompany.com/node/37815/print">this</a> article about a GE jet engine manufacturing plant in Durham, NC. It's definitely worth a full read, but in the interests of brevity I will summarize the salient points:<br />
<ol><li>This plant successfully competes against other engine manufacturing plants both inside and outside of GE, including off-shore manufacturers that have labor costs that are pennies on the dollar compared to US labor costs.</li>
<li>Only 1/4 of engines from this plant ever have a single identified defect (almost always cosmetic). 3/4 of the engines produced here are <b>defect-free</b>.</li>
<li>There is no management layers. There is a Plant Manager, and the manufacturing teams. Within the manufacturing teams there is only one worker classification</li>
</ol><div>In 2008 this plant made a decision to start manufacturing a new engine that was in increasing demand and already being manufactured by other GE plants. Within 9 weeks of that decision the plant shipped their first engine, at a cost approximately 12% less than what other GE plants that have been manufacturing that engine for years were delivering it at.</div><div><br />
</div><div>In the world of manufacturing a 12% cost reduction is a phenomenal achievement. To achieve that with the very first engine shipped is unheard of.</div><div><br />
</div><div>So why isn't GE doing everything in their power to replicate how the Durham plant operates with all of their other manufacturing plants? Is the senior management in GE too incompetent to recognize that a 12% decrease in manufacturing costs is a good thing? Not likely.</div><div><br />
</div><div>At the end of the article the Plant Manager of a different manufacturing plant is quoted as saying "I think what they have discovered in Durham is the value of the human being. Here we have people that turn wrenches. In Durham they have people that think.". </div><div><br />
</div><div>It's clear that GE understands why and how the Durham facility does what it does. But it is equally clear that GE isn't rushing to replicate the Durham model elsewhere. Why? Because that model is too complex to replicate. You cannot achieve the same results by mimicking the process. You also have to replicate the people. Remove the people that make the process work and you have a disaster in the making.</div><div><br />
</div><div>GE is smart enough to know that a manufacturing disaster leads directly to massive real world costs. Have a few jet engines fail in flight due to manufacturing defects and GE is quickly out of the jet engine business. But what about other practices that do not translate so clearly to the bottom line?</div><div><br />
</div><div>Let's look at social media engagement. There is a lot of pressure on business today to "get into" the social networking space lest they be left behind. Engaging social networking is a tricky business because you cannot control the conversation, you can only participate in it. Last year <a href="http://www.bnet.com/blog/businesstips/nestles-facebook-page-how-a-company-can-really-screw-up-social-media/6786">Nestle</a> decided that they were going to squash the practice of Facebook users using an altered Nestle logo as their profile picture. Their subsequent handling of the conversation has become legendary in the social networking sphere as a perfect example of how not to interact with your community.</div></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><br />
How did Nestle find itself in this position in the first place? Complexity. They "knew" that they needed to be engaging in social networking lest they be left behind by their competitors. Unfortunately they did not properly understand the complexities of engagement with customers via social networking until too late. Fear of losing ground in the marketplace led to imperfect mimicry of the complex practice of engaging social networking. Nestle would have been better off completely avoiding any social networking engagement.<br />
<br />
Agile is no question a complex practice. For every story you read about how Agile has become a mainstream practice there is another that laments the fact that Agile adoptions are mimicry at best and not true adoptions. William Pietri (whom I have joyously crossed swords with in other forums) has a great <a href="http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/">post</a> about this lack of true adoption. The telling quote from the article:<br />
<br />
"<span class="Apple-style-span" style="color: #444444; font-family: 'Lucida Grande', Verdana, Arial, sans-serif; font-size: 12px; line-height: 18px;"><strong>I think there is a vast army of supposedly Agile teams and companies that have adopted the look and the lingo while totally missing the point</strong></span><span class="Apple-style-span" style="color: #444444; font-family: 'Lucida Grande', Verdana, Arial, sans-serif; font-size: 12px; line-height: 18px;">."</span><br />
<br />
As we've seen, mimicry of a practice is not the practice. Without the actual practice you cannot reap the benefits. If we cannot clearly show the benefits of Agile within our own software industry are we going to convince the Boardroom to flock to Agile just because we say so?<br />
<br />
Of course! If ignoring actual results in favor of a convincing sales pitch is good enough for politicians, it's certainly good enough for us. Vote Agile! Change you can believe in (this time we mean it)!<br />
<br />
Seriously, I believe that there are two paths to establishing Agile as a valid winning business strategy. Let's take a quick look at these paths:<br />
<ol><li>Clean up our act. We've done a great job of selling the software industry on the fact that attending a three-day certification seminar where the only critical evaluation of your Agile skills takes the form of a one-page written test, the answers for which are usually dictated by the course facilitator. If we're going to sell Agile, we need a proper means of effectively measuring Agile. When someone comes to me claiming to be a Certified Scrum Master, I want to see proof that they have the ability to eliminate obstacles or conduct stakeholder feature negotiations effectively, not proof that they were capable of keeping their butt in a chair for three days. If an Agile coach shows up and promises full Agile adoption in anything less than a year of ongoing engagement with the team I want to see how well their previous clients have adopted Agile.</li>
<li>Beat them at their own game. There is no question that there are teams that are truly Agile, that deliver value frequently and consistently. There are enough of them now in the software industry that they have already become the "shining example" of success that the rest of the industry is attempting to duplicate. There was a tipping point when there were enough of these successful teams in the software industry talking about their success to allow the concept of Agile to become mainstream within the software industry. There are businesses out there right now that are winning at business in an Agile manner whether they know it or not. If we can properly market these businesses as Agile, how many more are needed to reach our tipping point?</li>
</ol><div>Sadly, although I am passionate about the first option, I am also a realist enough to realize that there is no way we'll convince the hordes of coaches, trainers and even certification bodies out there to clean up their act. There's far too much money at stake for them to do anything different. And unless their customers realize that they aren't getting what they are paying for, there is no impetus for change.</div><div><br />
</div><div>It's the second option that I think has the best chance for success. There is a part of me that feels like giving up on the dream of true mainstream adoption of Agile (for software or business in general) is a personal failing on my part. But the reality is that Agile is a complex practice, and nothing we can do will reduce that complexity. Complex practices are doomed to be understood and exploited by only a small percentage of businesses and at best mimicked imperfectly by the majority.</div><div><br />
</div><div>So if we want to see Agile win acceptance outside of the team room we need to take an active hand in creating the success stories that lead to the mainstream acceptance tipping point. If we're happy with what we are achieving in the team room it's time to take those successes and bring them into the board room so that other parts of the business can start to realize the value of Agile as a means of conducting business.</div></div>Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com6tag:blogger.com,1999:blog-2123916488544905831.post-15679213401882920742011-02-23T19:28:00.000-08:002011-02-23T19:28:30.146-08:00Why isn't agile "winning"? (part 1)Over the weekend I received a comment from John Rusk (<a href="http://www.agilekiwi.com/">www.agilekiwi.com</a>) about one of my "Ahas" from 10 Years Agile. He thought that my musing about whether Agile really matters or not was more of a reflection on how companies do business as a whole as opposed to a question about Agile.<br />
<br />
His comment (which I do agree with in principle) caused me to realize that I hadn't quite captured the essence of the thought that led to that "Aha". Since I believe that this is one of the key issues facing the ongoing adoption of Agile both inside and outside of software development, I think it's worthy of its own posting. Well, that plus this is my blog, so the voting on topics is a bit skewed...<br />
<br />
Let's start with some ground rule assumptions:<br />
<br />
<ol><li>"It's a Dog Eat Dog World" - The capitalistic economic model creates an evolutionary "survival of the fittest" environment for companies.</li>
<li>"Show Me The Money" - The measurement of success for companies operating in this environment is money (revenue / profitability).</li>
<li>"Keeping Up With The (Dow) Joneses" - Business practices that have a positive impact on money tend to become adopted by other companies (akin to how beneficial genetic mutations spread through a population).</li>
<li>"Blink And You Missed It" - The rate of propagation of these "mutations" can be exceedingly rapid (days and weeks versus years) so it is good business to pay attention to what others are doing.</li>
</ol><br />
Assuming all of the above is true, you have an environment that is highly tuned to detect, adopt and innovate business practices that directly influence the bottom line. A couple of examples for your amusement:<br />
<ul><li>The Web - Say what you will about the insanity of the dot-com bubble, there was a solid business "mutation" at the root of it - the realization that the web provided a unique new channel to customers for companies. Two business behemoths of today trace their birth back to the heady days of the dot-com era - Amazon and Google.</li>
<li>Lean Manufacturing - Most discussions of the origins of Lean credit Toyota for taking earlier concepts espoused by Henry Ford and others and adapted them to the dynamic challenges of the modern manufacturing industry. Today you would be hard-pressed to find any manufacturer that does not use Lean practices to some degree. This practice has been so successful that it has actually "mutated" into the Agile movement.</li>
</ul>Interestingly enough, both of these examples of business practice "mutations" also contain an important cautionary lesson that may inhibit adoption of Agile outside of software development. Consider the following:<br />
<br />
Dot-bombs. For every success story coming out of the dot-com frenzy, there are hundreds of failures. In most cases the failures were entirely predictable in that they failed to "Show Me The Money". What would possibly motivate otherwise sane business minds to deviate from focusing on money as a measure of success?<br />
<br />
Henry Ford's Lean - According to <span class="Apple-style-span" style="font-family: inherit;"><span class="Apple-style-span" style="line-height: 19px;">Taachi Ohno (Credited with developing TPS - principal progenitor to Lean), he "learned it all from Henry Ford's book". If that were truly the case, why did the company that Henry Ford founded fail to "Keep Up With The (Dow) Joneses"? You'd think somebody at Ford would have at least one copy of Henry's book around, right?</span></span><br />
<span class="Apple-style-span" style="font-family: inherit;"><span class="Apple-style-span" style="line-height: 19px;"><br />
</span></span><br />
<span class="Apple-style-span" style="line-height: 19px;">In both cases the underlying cause seems to be a lack of understanding of the complexity of the business "mutation" that they were either pursuing or ignoring. </span><br />
<span class="Apple-style-span" style="line-height: 19px;"><br />
</span><br />
<span class="Apple-style-span" style="line-height: 19px;">In the case of the Dot Com bubble, a few extremely high profile IPO's (theGlobe.com) and company sales (Hotmail) demonstrated to the market that there was a vast new frontier of business opportunity on the internet. Unfortunately for the market as a whole, there was a lack of realization that the valuations of these high profile deals were based on a speculative model (% of market share) and not a traditional valuation formula (revenue times X). Establishing the value of a company based on market share alone is quintessential "betting on the come". This is not to say that it does not have it's place. In the case of Microsoft buying Hotmail this was a classic example of where this sort of valuation makes sense. </span><br />
<span class="Apple-style-span" style="line-height: 19px;"><br />
</span><br />
<span class="Apple-style-span" style="line-height: 19px;">But the larger business community simply saw that the valuation of internet companies was shooting through the roof and rather than taking the time to understand the complexity of this new frontier, companies settled for mimicking the outward appearance of moving to the internet. We all know how that played out.</span><br />
<span class="Apple-style-span" style="line-height: 19px;"><br />
</span><br />
<span class="Apple-style-span" style="line-height: 19px;">With Ford and Toyota, the complexity comes from a different angle. Henry Ford was definitely on to something with his fledgling "Lean" practices. What Henry (and Ford as a company) failed to grasp is that the challenges facing manufacturers are not just static (waste in manufacturing processes) but also dynamic (supplier is late in delivering critical parts). Unfortunately for Ford and other US manufacturers, the next several decades would not provide them with the sort of environment that would force them to innovate to improve quality and productivity. This wasn't the case in Japan, where a weak post-war economy forced manufacturers away from reliance on mass-production economies of scale to remain in business.</span><br />
<span class="Apple-style-span" style="line-height: 19px;"><br />
</span><br />
<span class="Apple-style-span" style="line-height: 19px;">When Japanese autos did show up on US soil, the US auto manufacturers initially failed to understand the different practices that Japanese manufacturers were following. By remaining at a low price point and steadily improving quality, the Japanese manufacturers stayed in the market when by US manufacturer standards they should have been out of business. US manufacturers like Ford failed the "Keeping Up With The (Dow) Joneses" principle, which set them up for being hit square by "Blink And You Missed It". By the time they realized that something was up, Japanese manufacturers had surpassed them in quality and were taking away significant market share - a state of affairs that persists to this day.</span><br />
<br />
Hopefully by this point we have established that:<br />
<ol><li>The business community as a whole is quick to recognize and adopt practices that have a clear impact on "success", namely money.</li>
<li>The business community as a whole is not so great at recognizing when a practice that has a clear impact on money is complex. As a result the tendency is to mimic the appearance of the practice as opposed to adopt the actual practice.</li>
</ol>So what does that have to do with Agile? Good question. If you haven't already worked out where this is going, you'll have to wait until the next posting when I actually try to answer the question of "Why isn't Agile 'winning'?".Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com1tag:blogger.com,1999:blog-2123916488544905831.post-1942321864827151192011-02-16T13:24:00.000-08:002011-02-16T13:27:22.315-08:00My "Ahas" from 10 Years AgileThe Salt Lake Agile Roundtable discussion group (<a href="http://tech.groups.yahoo.com/group/sl-agile/">Yahoo Discussion Group</a>) has a little tradition that I've become quite fond of over the years - at the end of the meeting everyone in attendance has to provide at least one "Aha" moment (something during the discussion that stuck with you) from the discussion. Not only does it reinforce important concepts by repetition, once you know that you need to communicate these to others you start to pay more attention to the conversation. Which in turn gives you more "Ahas" and so on.<br />
<br />
Once I discovered that I somehow connived myself onto the invitation list for the recently completed <a href="http://10yearsagile.org/">"10 Years Agile"</a> conference (#10yrsagile for twitter fans), it was inevitable that there'd be some forthcoming "Aha" moments from the conference that I'd want to be sharing with whoever would listen.<br />
<br />
At this point it's probably worth mentioning that my particular style of Agile is the Crystal family of methodologies developed by Dr. Alistair Cockburn. I became a fan of Alistair back in 2002 when we were speaking at the same local conference on software development, and over time that relationship has developed to the point where I consider him both my mentor, and one of my closest friends.<br />
<br />
I do have a real point to my blatant name-dropping. Alistair had asked me to publish my "Ahas" somewhere so he could do whatever it is that he wants to do with them. So with that in mind, here are my "Ahas" from 10 Years Agile.<br />
<br />
1) Leadership and Vision - There was a lot of discussion around the concept of "leadership" in the Agile community. Makes sense, but it seems to me that discussing leadership without a parallel conversation about vision isn't going to make a lot of sense. If anything perhaps we should focus first on defining what our shared vision is, and then address the issue of leadership. Since it's clear that we've already got leadership in play (see "elephants" below) I am not so sure that more or different leadership is going to make as much a difference as we'd like.<br />
<br />
2) Defining and realizing "Value" - One of the most prevalent issues was value - defining it, quantifying it, increasing it, you name it. Value was definitely one of the more pervasive issues in the discussion. The specific "Aha" that occurred to me was that we may be over-simplifying our discussion of value in relation to an Agile organization. The value of Agile means different things when you move between individual <=> team <=>organization. The ways that you measure value for each are going to vary greatly. Job satisfaction as a value measurement means a lot to an individual, but not much to the organization. Return on investment is a key value for the organization, but how important is that to the individual?<br />
<br />
3) Practices and Tools outside of development - One of the more interesting frustrations I had during the course of the conference was the seemingly pervasive attitude of "Agile is for software". At one point in the discussion a participant claimed that a team isn't Agile unless they have followed specific software testing practices. Later in the conference there was a heated debate about whether the term "engineering" should show up in one of the outputs of the conference. I am not debating the need for specific practices that will improve work products. What irks me is if we expect Agile to become a tool for the organization as a whole, don't we think that the tools and practices of the CEO, or the Marketing team have the same importance?<br />
<br />
4) Elephants in the room - Of course we're talking about the prevalence of the "certification" entities as the most visible public face of Agile to the world. It was clear that there wasn't a lot of love in the room for the value of certifications as they exist today in the Agile world. What didn't seem to be so clear to others (or maybe I just didn't have the right conversations) was the fact that there isn't much we can do about them other than work with them or put out a better product. Take an organization like the Scrum Alliance. Are they going to change their business practices based on outcry from the rest of the Agile community? Not a chance. By the best definition of success we have in a capitalist system, they are successful because they are making money. If we don't like what they are doing, there's a proven formula for dealing with this. Compete with them and force them to change by way of a superior offering.<br />
<br />
5) From Certification to Evaluation - The real problem that I see with #4 above is the fact that the business community is accepting certifications as if they somehow predict job performance or improve the chances of successful adoption. Unless you can show me what your failure rate is for people attempting to certify as whatever title you're giving, I'm not the least bit interested in that certification. What amazes me is that the certification bodies themselves aren't more concerned about this. Without critical evaluation of the knowledge and skills that are being trained how does the certification organization know how effective its educational effort is?<br />
<br />
6) Does Agile really make a difference? - Not so much a question that showed up at the conference, but one that kept running around in my head, kicking over garbage cans and spray-painting the cat. As mentioned in #4 above, a capitalistic society provides some very clear measures of success, and is as Darwinian an environment as you can get for principles and practices that affect the bottom line. It's clear we've made excellent progress over the past 10 years, but it's still not so clear to me why businesses aren't beating down the door to really adopt Agile throughout the enterprise and not just be buzzword compliant. If we expect Agile to move from the dev team out to the larger organization we're going to have to be much clearer about defining and proving the real value of Agile as a better means of doing business.Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com1tag:blogger.com,1999:blog-2123916488544905831.post-38230127844680135152011-02-14T17:20:00.000-08:002011-02-14T20:06:58.071-08:00"Agile Sadist". Really? REALLY?!?Yes, really.<br />
<br />
No, I don't show up at work decked out in a full leather jumpsuit, whip in hand, impatiently waiting for the first hapless developer to come scuttling by. If my professional colleagues and co-workers can be believed, I'm actually not that bad to work with on a daily basis, at least as long as there isn't any Dilbert-esque sort of shenanigans going on in the organization.<br />
<br />
Before I dive into why I'm risking guilt by association with one of the more "colorful" genres of adult entertainment, let's clarify something about what Agile means, at least to me. Around 4 or 5 years ago I was sitting with Jeff Patton, discussing whatever it was at the time that was interesting to us, when an "aha" showed up in our conversation. It seemed important enough at the time to warrant writing down, so we did:<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhM2d9mh_9Q-GZgYMFPh7aGnu_4wDw2SeivZXHf-kpwF_sCBmZotNudb06tEhTtEeW3pAdRx_PF6yUzEhg49osIpo5MsiX31qJFgd2r9VG6xYzUKnZPIAsrBRWlTmwy3VAu6jjAc5EHkd0/s1600/cultural_adoption_card.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="120" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhM2d9mh_9Q-GZgYMFPh7aGnu_4wDw2SeivZXHf-kpwF_sCBmZotNudb06tEhTtEeW3pAdRx_PF6yUzEhg49osIpo5MsiX31qJFgd2r9VG6xYzUKnZPIAsrBRWlTmwy3VAu6jjAc5EHkd0/s320/cultural_adoption_card.PNG" width="160" /></a></div><br />
It says: "Agile adoption isn't process adoption - it's culture adoption"<br />
<br />
Culture is defined as <i>"<span class="Apple-style-span" style="font-family: inherit;"><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">the</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">behaviors</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">and</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">beliefs</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">characteristic</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">of</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">a</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">particular</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">social,</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">ethnic,</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="color: #333333; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">or</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="color: #333333; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">age</span></span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"> </span><span class="Apple-style-span" style="color: #333333; line-height: 16px;"><span id="hotword" name="hotword" style="background-color: transparent; color: #333333; cursor: default; line-height: 1.25em; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; position: static;">group</span></span></span>"</i>. Practices that do not align with underlying cultural principles are at best ineffective. Take the example of the stand-up meeting. How well does the stand-up give early warning of trouble if there isn't sufficient personal safety within the culture to allow someone to bring bad news to the attention of the group?<br />
<br />
But I digress. Back to the point.<br />
<br />
The "Sadist" term was chosen (very carefully, I might add) for two reasons. The first, and most important, was a realization that individual and organizational behavioral change isn't just influenced through positive means. Whether we like it or not, humans have evolved more mechanisms for changing behavior based on negative stimuli than we have for positive behavior. It doesn't take a three day certification seminar to teach you that fire isn't something that should be handled with bare skin.<br />
<br />
Before you jump to conclusions here, understand that I am not advocating that your team be used for practice by novice hibachi chefs if they fail to deliver a release on time. But understand that pain and discomfort, whether it be physical, emotional or intellectual, is an effective tool for changing behavior.<br />
<br />
Not exactly a happy thought, is it? Rest assured that unless the organization that you're trying to effect change in is the military or some sort of terrorist group, physical pain isn't on the menu. To be honest, even the term "pain" isn't on the menu. When I talk about using "pain" as a means of effecting cultural adoption, what I really mean is "discomfort".<br />
<br />
Here's an example. Once upon a time there was a small company that has more than one stakeholder for a specific software product in the same office as the development team. Each time a stakeholder needed something in the software, they'd go to an individual on the team and demand that it be done now, regardless of what was being worked on. It suffices to say that there was a fair bit of thrashing going on.<br />
<br />
To change this "back-channel feature request" behavior, I decided to make sure that the discomfort of shifting priorities was felt directly by the stakeholders and not just the development team. The stage was set by getting the stakeholders to agree to discuss any changes with the rest of the stakeholders before they could go into the current iteration. As each stakeholder had been bitten by changes before, they readily agreed to the change. I think it was a day later that a stakeholder came in with a request. Their argument of "it'll just take a minute" didn't dissuade the team from calling a stakeholder discussion on the spot. Not only did the stakeholders deny the change, they admonished the originating stakeholder for disrupting the team.<br />
<br />
It didn't take many of these negotiations to change the behavior of the stakeholders.<br />
<br />
The second reason for choosing "Sadist" is a bit more personal. More than once in my life I have been accused of unnecessary hyperbole to get a point across. Guilty as charged. What I've learned though is that hyperbole is a good tool for generating interesting discussions. If I had fashioned myself as an "Agile Organizational Discomfort Enhancer", I'd probably lose interest in what I had to say before I'd even finished forming my response. But as a self-professed "Agile Sadist", I can honestly say that there has been no lack of interesting discussions to be found in the Agile community.<br />
<br />
Oh, and another interesting thing about hyperbole - it's a sort of a hybrid intelligence/awareness test. Most people don't look past the hyperbole to see what is really there. For the few that do, it's nice to have them announce themselves by saying:<br />
<br />
"That's interesting. What do you really mean by that?".Jonathan Househttp://www.blogger.com/profile/14159138478001797747noreply@blogger.com1