TFS v. SVN: 2012 update

TFS 2012 offers some new features to make life easier for developers who prefer the SVN/DVCS style of version control. It’s a better option than ever, especially for unifying teams with diverse OS/platform/language development needs.

A while back, my colleague Martin wrote a nice summary in response to some critiques of TFS 2010 when compared to Subversion (SVN).  I happen to be working on some documentation for a customer on this topic, I thought I might share what’s new now that TFS 2012 RTM is right around the corner.

TFS objection #1: Branch confusion

Fixed in 2010 and still fixed in 2012.  :)

TFS objection #2: Checking out

If you want to edit a file you need to check it out for edit so that it’s listed in Pending Changes window after it’s changed. If you edit a file directly in Visual Studio it checks it out for edit automatically; however, if you make the changes outside Visual Studio (you need to change Read-only property prior to that) and forget to check it out for edit in Visual Studio the file is not listed in Pending Changes window. Consequently, the risk of not including that item while making a check-in increases (I personally experienced that a couple of times….) – Jarosław Dobrzański, TFS vs. Subversion

I have heard this from many other SVN users and I completely agree and understand the perspective. Although I find it difficult to understand how you know which files you have checked out when you don’t have this, it looks like all the source control products are going in this distributed direction and I will just have to go with the flow. – Martin Hinshelwood, TFS vs. Subversion Fact Check

Martin was right!  They are all going in this direction!  TFS 2012 now supports Local Workspaces and in fact new workspaces are even Local by default.  This means:

  • Edit, add, or delete any file
  • In any editor, not just Visual Studio
  • Without an explicit check-out
  • Pending Changes detects all the changes for check-in

But what if my team still wants server-side visibility when someone has checked out a file?  Explicit check-outs are still available, and Server Workspaces still exist.  Best of both worlds!

TFS objection #3: Windows only

Fixed in 2010, and still fixed in 2012!  Team Explorer Everywhere is a full-fledged member of the TFS suite and offers command-line support for Mac OS and Linux, plus an Eclipse IDE plug-in.  And one of the major pain-in-th… pain points for non-Windows users was having to interact with explicit check-outs through the command line, which is fixed in 2012 thanks to Local Workspaces!

TFS objection #4 and #8: Reverting changes

Fixed in 2012!  Rollback is now supported in the UI.

TFS objection #5: Cost

New options in 2012!  TFS Express is free for small teams.  Team Foundation Service is now in open preview; at the moment it’s totally free, and they’re promising to always have a free version though we don’t know how full-featured the free one will be.

TFS objection #6: Difficult to install

Fixed in 2010!  Here’s a video of my colleague Steven Borg installing TFS 11 Beta in four minutes, 58 seconds.

Not fast enough for you?  OK, how long does it take to enter your Windows Live ID and password into Team Foundation Service…?  :)

Now, if you’re upgrading something with more complex requirements (customizations, consolidations, compliance) or you need to migrate from other tool(s), of course that might take longer than five minutes.  But it’s doable.  Northwest Cadence has lots of experience with upgrades and migrations, including the new TFS 2012, and we’d be delighted to help.

TFS objection #7: Switching between branches

Same as before.  There are some advantages to the way TFS does it, but basically it’s just a preference thing.


One great big change (Local Workspaces) and a few little ones (rollback in the UI, along with baseless merge in the UI and other improvements) make TFS a more comfortable option for developers who’ve previously used and liked SVN.  Where I think this is the best news is for diverse cross-platform dev shops, which are proliferating especially as more organizations need to move into mobile.  TFS with TEE is a really, really good option to bring all of your developers, regardless of language or OS or platform or geographic location, together around a common ALM solution, and with 2012 it’s a better choice for developers than ever.

Update 1, July: DVCS

DVCS <> SVN.  My #fail, and I have done lots of reading and querying to properly learn the difference.  Thanks to Kyle for pointing that out.

Update 2, August: Actually, DVCS…

TFS is getting on the DVCS bandwagon!  There’s a new bridge that syncs between a Git repo and TFS (Git, not github).  It’s a cross-platform implementation and open source on CodePlex.

This is a great option for organizations, especially cross-platform shops: take advantage of the things TFS does well (integration, traceability, metrics) while still giving dev teams the flexibility to work with their source the way they want to.

Update 3, January: MOAR DVCS!

Real, full-fidelity, Git as the SCM under TFS.  Not a bridge or a sync, just Git for TFS.  First-class integration and traceability between source and everything else ALM.  Woo.


Where’s Cheryl?

Lately, Cheryl’s mostly heads-down on a long-term client engagement.

But, if you’re a fan of my quirky public speaking style and want to stalk me* virtually or in person, I can help!  Check out my new Events page for a complete list of upcoming public & private webcasts & in-person appearances.

When I’m traveling, I’m always on the lookout for a nerd dinner or user group meeting I can crash, so let me know what’s up in your area!

(*That’s a joke.  Please don’t really stalk me.  That’d be weird.)

Seattle Scrumpocalypse 2012

Are there any conditions in which a Sprint’s timebox can legitimately be extended?  I think I might have found one.

In my Scrum-damentals webcast I’m pretty strict in advising that teams should not extend the timebox of a Sprint, even when things go pear-shaped.  Why not?

You and your team have certain goals as you’re getting ramped up with Scrum:

  • Learn your true velocity based on real-world measurements
  • Improve your estimating and forecasting capabilities through regular feedback
  • Refine your story sizing and task breakdown skills
  • Develop a comprehensive definition of done (e.g. don’t overlook needed work)
  • Over time establish reliable metrics for future forecasting

Extending a Sprint in order to complete all of its deliverables undermines all of those goals.

Besides, there are better alternatives.

  • With the Product Owner’s approval, you can reduce the scope of the Sprint at any time for any reason
  • I personally like a Kanban WIP (work in process) limit to be in place from the start of the Sprint, because if you need to cut scope mid-sprint, it’s a lot nicer to have some completed stories (credit!) and some unstarted stories than all half-finished ones (no credit for any of them!)

This week one of my Scrummy friends presented me with an interesting challenge and got me to reconsider—or rather, refine.

You may have heard that we had a little weather up here in the Northwest.  Being the tech city that we are, nearly everyone (who doesn’t already do this full-time every day) retreated to work from the comfort of their living room and their fleecy pajama pants.  I won’t speculate on what this does to teams’ productivity, but we can safely say that widespread power outages that started on Thursday knocked out all but the most hardcore workaholics (running their laptop on battery, tethered to their 4G smartphone, recharging off the Prius in the driveway, you know the type).

My friend spent his week trying to salvage a Sprint which was scheduled to end on Friday.  He phoned in each day to his daily Scrum.  Standing up isn’t prescribed by Scrum, but lots of teams appreciate the value of a standup and he indeed stood up, pacing the kitchen during the requisite 15 minutes.  They lost time to and were blocked by the storm in various ways that I don’t know all the details of, and on Wednesday he lamented to me that, with all they’d have to cut from scope, they were facing a “failed Sprint” because you “can’t” extend it, not even to account for the weather.

I gave this a little thought and asked, “didn’t you determine your Sprint backlog based on your team’s capacity?”  Of course, he said.  “If a federal holiday fell in the middle of your Sprint and your entire team missed a day, would you count that against their capacity or would you plan around it?”  Don’t be silly, you wouldn’t count a federal holiday as a team Sprint day any more than you’d count a weekend, he said.  (Neither one of us is the tethering/Prius type.)

“So, if nature drops the equivalent of a federal holiday into the middle of your Sprint, why not move the Sprint around it?  If you move the Sprint end date by one day, aren’t you just keeping the Sprint the same length it was before?  The same duration your team had in mind when it accepted the scope?”

So, in my mind, this is a legitimate reason to change the end date of a Sprint.  I’m not sure it even counts as “extending”—the point is to keep the capacity constant.

I also told him that I don’t remember seeing “failed Sprint” in the Scrum Guide

Finally, if you think a little snow is a bad reason to lose productivity during a Sprint, Seattle sportswriter Art Thiel and I invite you to shut the hell up.

Keep warm, Seattle!  And don’t run your Prius inside!

Scrum for One

My customer is a team of one, which means that by the Scrum Guide he can’t be “doing Scrum”.  Whatever.  Scrum still has a lot to offer in his situation.

"Same procedure as every year, James."

My sächsische (Saxon) friends introduced me to the traditional New Year’s programme Dinner for One, in which elderly Miss Sophie’s loyal manservant James, due to personnel constraints, must attend to every detail of her 90th birthday party himself.

Last month, I visited a customer to perform NWC’s first official Scrum Health Check, a new offering I stole adapted from my colleague Martin’s blog post (“Are you doing Scrum? Really?“).  I sent lots of advance-prep materials and brought a beautifully-crafted checklist that I planned to use to determine their Scrum baseline.  But all that went out the window when I arrived onsite and found that my customer was a Scrum Team of One!

And then I tripped over a tiger

Me: First question.  Do you have Development Team(s) of 6±3?

Customer: Um, no.  There’s one other guy, sometimes, but we had this re-org and he reports to another manager now so… yeah, it’s pretty much just me.

Me: All righty!  Our Scrum Health Check is finished.  You are not doing Scrum.  Now, let’s talk about how you can use Scrum to make your… er, team… most effective in your situation.

And that’s what I’m about with Scrum.  Instead of throwing the entire Scrum Guide out the window, we kept it around and talked all day about the other Scrum practices my customer could use: in particular, we identified an ordered backlog and proper structure and focus for the biweekly Sprint Planning and Reviews/Retrospectives, to provide transparency and improve management buy-in.  These were his most urgent needs and we both agreed that Scrum could help—that’s why he picked it in the first place!

"Well, I'll do my very best!"

I consider myself fortunate to have arrived on the Scrum consulting scene right at the time when Scrum is making changes to become less rigid, less religious, and more widely useful (without diluting the structure that makes it so effective).  It would be a stupid waste (for all of us) to turn my customer away from Scrum just because he isn’t canon.

Fiat 500 Review

I finally got behind the wheel of a Fiat 500.  I couldn’t find a comfortable seating position, which is a major problem, but the car is still super-cute and fun to drive.

Enterprise Rent-a-Car at the airport in San Jose, California is set up so you step out from the rental booth with an agent and a blank contract, and walk the rows together to select your own car.  They very, very shrewdly placed a Fiat 500 next to the booth so you can’t miss it, and I joyfully leaped into the obvious trap:

“Is that Fiat 500 yours?  Is it available?  I want it.”

“But of course, madame.  It’s a specialty class, a mere $10 per day extra.”

I took exactly enough time to calculate in my head the cost for a two-day rental before agreeing.

I drove my Fiat 500 about 10 miles from the airport to my brother’s apartment in San Jose, and then about 85 miles from there to Vacaville, and finally about 40 miles from Vacaville to the Sacramento airport.  Here’s my review of that experience.


There is absolutely nothing cuter on the road in the USA than this car.

  • Cute exterior, duh.
  • Cute seats with cute round headrests
  • Cute inside door handles that push/pull to lock/unlock in a cute way

    Faux enamel

  • Really cute shiny dashboard that looks just like old school enameled metal; preserve the illusion by not touching the cheap plastic it’s actually made of, which will surely scuff and come to look cheap over time
  • Cheap-looking and -feeling plastic bubble-shaped gearshift lever
  • Somewhat garish orange electronic dash display with ugly LCD font


Doesn’t feel tiny.

  • Fast; I was doing 75 up to nearly 85 without realizing it
  • I passionately hate automatic transmission and this car didn’t change my mind
  • Steering is effortless on city streets and in parking lots but wild on the highway, I’m surprised I didn’t get called in for my wild veering at speed on the way to Vacaville
  • Bumpy on Highway 87, but I either got used to it or I-680 was smoother later
  • Cruise control works nicely

Sport Mode

Midway to Sacramento, I RTFM’d and accidentally discovered this feature.

“The Sport mode increases steering feedback to the driver with slight increase in effort and changes the transmission shift schedules for more aggressive shifting.”

It works.

  • I almost didn’t hate automatic transmission to the point of violence
  • I stopped oversteering all over my lane at speed; it was easy to stay steady
  • It ruled

Seating Position

This might be the dealbreaker, but I will try a few more options.

  • I normally slide my seat back all the way
  • The good news: plenty of legroom, more than my Corolla even
  • The bad news: couldn’t reach the steering wheel, and it doesn’t telescope
  • Also can’t tilt it down enough to reach the bottom of the wheel while resting my arm on my knee

There was no comfortable driving position; even sitting closer and straighter than normal, my arms & shoulders were outstretched and tensed up the entire time (a 1.5-hour drive and a 40-minute drive) and my shoulders, neck and back still ache two days later.

  • Driver’s side blind spot checking is blocked by a big roof support, but I got the hang of looking around it
  • Seat belt anchor height is not adjustable; WTF, it is 2011, seriously
  • It’s tall and sits high; I actually looked down into a Mini Cooper when I passed it


I didn’t find anything on the car itself to tell me whether I had a Pop, Sport or Lounge model, but the rental receipt suggests perhaps the base Pop.

  • Automatic window switches are on the center console, not the doors; they’re cute there but I found the placement annoying after just one drive-thru

    Alleged back seat

  • Windows have one-touch-down but not one-touch-up; it is 2011, I demand both
  • Cool switchblade-style retractable key
  • Keyfob is ridiculously large, and Enterprise made me carry two of them
  • Trunk button on the keyfob unlocks, but doesn’t unlatch, the hatchback
  • No hatchback release lever inside the car that I could find
  • Audio Aux In hidden inside the glove box, with a cute tiny cargo net to hold the iPod, if I had brought a 3.5mm cable, which I hadn’t; manual says some models come with USB iPod in in the same spot, which I had cable for, but my model didn’t
  • This is insane, but I could not find the ACC setting on the ignition switch, only ON or OFF, even though the manual suggested that ACC should exist
  • Lane Change Assist feature, extremely clever: lightly tap the turn signal lever and it flashes exactly three times and stops on its own; I loved this, but the light-tap required a surgically precise amount of pressure and precise direction of tap to get it right so it only worked about half the time for me
  • My 1998 Corolla automatically detects when it’s dark out and turns its own headlights on; it is unacceptable for me to have to do this myself in 2011
  • The back seats mostly aren’t


I didn’t see a single other Fiat 500 on the road during two solid days in the Bay Area, which ought to be its demographic.  Not a good sign for the business.

I still like the idea of this car, and I might have to part with my beloved 1998 Corolla someday, so I’ll probably test-drive a Sport with manual transmission at some point and see whether I like it any better.  Maybe the dealer can help me get the seat and wheel adjustment right in some way that I missed.


  • I forgot; obviously what I want is an Abarth.  An Abarth and a massage therapist.  Totally worth it.
  • As I suspected, sales of the Fiat 500 have been lousy so far.  “While it’s too soon to regard Fiat as troubled, Chrysler will be watching carefully to make sure sales performance continues to gain strength after the slow start.” (Fortune/CNN, 3 Nov 2011)
  • Abarth == macho cuteness?  Sign me up!  “The Abarth, a souped-up 500, arrives after an announcement that slow sales of the Fiat 500 in North America were prompting a cut in production. The parent company is hoping that throwing a little horsepower and macho sex appeal at the problem will excite American audiences with visions of new possibilities for the 500.” (NYT, 16 Nov 2011)
  • I can attest: “Chrysler’s ads for the Fiat 500 starring Jennifer Lopez have become a lightning rod for the car’s disastrous launch.” (BusinessInsider, 22 Nov 2011)  I don’t watch commercials if I can help it, so I’d never even seen it, but my friends on FB didn’t hesitate to mock me about it!  If Fiat distinctive cute is going to become Fiat unmistakable laughingstock, then yes, I would seriously reconsider whether I want to be seen driving one for the next decade.

Scrum Renaissance

Are you sick and tired of rigidity and attitude in the Scrum community?  Me too.  So is  Let’s get over it together so we can get some work done.

Stuff has been brewing in the Scrum world this autumn, and two big events aligned last month: the Professional Scrum Trainer global meetup followed by the ALM Summit.  I’m not a PST (yet), but the impact of the meetup was unmistakable as fired-up PSTs stormed the Summit and they and rolled out both conversations and official sessions with some of the new messaging around Scrum.

My PST colleague Martin is tackling a number of the substantive changes in his blog (“Are you doing Scrum? Really?” and others).  I think he captures well what I’m most excited about: the new language and the new approach do a lot to undo the rigidity and religious warring around Scrum.

To me, the first big hint of changes to come was when David Starr joined back in July.  In his announcement, he pointed out that he’s “more pragmatist than zealot” and wrote favorably about a long list of practices that many folks in the process community have made out to be “competitors of” or “incompatible with” Scrum for some reason.  I know David’s been involved in the world for a long time, but it struck me as potentially a big deal to have him officially on board.

Bringing a measure of tolerance to the process wars

In October, we got more evidence from that change was coming: “Scrum is Open for Modification and Extension“.  A coder might initially say “open to extension, closed to modification”, so it’s interesting to think about why they didn’t.  It’s gutsy for to put itself out there as willing to change the framework itself in response to community feedback.  Modification is formalized, which means it does not seem to be an invitation for immature teams to pick and choose and throw out and make up practices willy-nilly and call them “Scrum”.  I’m interested to see where that goes.

It had a good run

That brings us to the really big news: the death of Scrum But.

I have no doubt that Scrum But, as a concept, was intended to be helpful. I know this because I just finished co-authoring a slide deck built entirely around Scrum Buts: why your rationales are legitimate reactions to the difficulties of Scrum practice and should be heeded, and why a more thorough understanding of Scrum principles is almost always a better solution than a Scrum violation.  I am certain I was trying to be helpful.

Seriously, in the space of two weeks I went from “the trouble with your Scrum But deck is that you keep refusing to spell it with two Ts” to “you’re gonna have to throw out that Scrum But deck”.  Two weeks!  Is this a Renaissance or a Revolution?!

Scrum But is dead.  Long live the Scrum Curve!

The Scrum Curve: no buts about it

I stole this from Martin because it’s awesome and it’s a much more useful way to illustrate the point that matters: Scrum isn’t a boolean, it’s a continuum.  Teams may be doing Scrum to greater or lesser degrees.  Yes!  There is room for variability in practices that we can still call Scrum!  Now, instead of clucking (get it?) at teams for being “Scrum But”, we can help them refine and improve their Scrumminess to improve their performance. Instead of all or nothing, we can fully support incremental adoption and growth over time, including extension practices (like from Kanban) that working together take teams to Scrumfinity and beyond.

Update: It’s a good day for a Renaissance!  By delightful coincidence, rolled out their new front page today.  I’m excited to be engaged with what’s coming next!

Just look what they found space for!

ALM Summit: devgrrrl Evolution

I’m working on a blog post wrap-up of the 2011 ALM Summit experience, so today I did a little bit of white-glove research in the archives.

I can’t find archaeological evidence of my attendance at what was then still called p&p summit in 2006, but I know I was there because that’s where Peter Provost & Michael Puleio gave their “Agile Talk on Agility” which blew my mind and changed the way I do software and public speaking and made me a loyal Summiteer for life.

I did, however, find some real treasures: my p&p 2009 and 2007 (!) adventures in liveblogging.  They’re essentially my scribbled notes, so a lot of the actual content is completely unintelligible now, even to me, but they provide a window into my growth as an attendee and as a professional in this field.

Even at the time I was writing them, I knew perfectly well that those blog posts were an outlet for my insecurities as a dev and a #devgrrrl, so you’ll see lots of that in there (see also the posts in between, from TechEd 2008).  If you read them in chronological order, I think you’ll see a growing level of experience and confidence.

I switched to livetweeting the rebranded #almsummit in 2010.  By then, I was fully aware that the great value I get out of conferences isn’t the received wisdom from a speaker in a lecture hall and never has been and I’m not sorry.  (See also: my college, with an average class size < 20 and a high degree of informal access to faculty.)  In 2006, 2007 and 2009, it was clear that I learned more by talking with colleagues about the previous hour during the 15-minute coffee breaks than I did in the hour itself.  That’s why I always worked so hard to recruit a good group to come with me.  The other big change in 2010 was that I quit being afraid of the broader community, and I put myself out there to engage with them.  Maybe the interactivity of the Summit’s little Twitterverse helped: I started to see that highly skilled professionals struggle with the same issues as I do, or even struggle with issues my team had already, in our way, solved.  I even got retweeted!  In other words, I might have something to contribute!

Plus, I was thrilled to witness the impact of the community’s livetweeting on the entire 2010 Summit.  We stopped talking about Agile in a waterfall way (top-down, planned in advance) and started actually putting Agile Talk About Agility into practice (self-organizing, continuous feedback)!  It was like our collective lightbulb moment!  And, as Agile techniques are wont to do, it left me feeling smart and empowered.  I can do this!

The other big event in 2010, not recorded anywhere, was my chance meeting with Linda from Northwest Cadence during one of the aforementioned coffee breaks.  We hit it off, which set some slow-moving wheels in motion throughout 2011 and landed me where I am today.  It’s a good thing I’m not (too) afraid of the ALM community any more, because I’m up to my neck in it!

Stay tuned to the Northwest Cadence blog, where I’ll talk more about making the transition from acolyte to Platinum Sponsor at this year’s Summit…

Underpants Gnomes in Kanban

… or, no good joke goes unpunished

Kanban offers a lot of potential for targeted, specific, incremental change, but you will need to have or create a problem-solving culture to avoid stalling out.

Earlier this year I made the wisecrack around the office that my problem with Kanban is, it feels too much to me like the Underpants Gnomes:

  1. Visualize work
  2. ???
  3. Process improvement!

Northwest Cadence just got cheekier. You're welcome.

Steven, who thinks I’m funny, ran with it just a bit.

Last night at the ALM Summit, we had a great breakout (“Open Space“) session at which some serious agile luminaries held forth on the theories underpinning both Scrum and Kanban and process improvement in general.  Steven outed me and my joke, so now I think the heat’s on.  Can I unpack this idea and turn it into real learnings, or was it just a cheap shot?

Well, let’s put the obvious out there first.  Although Kanban does literally mean just “visual card” or “visual board”, Kanban in the context of software development process improvement doesn’t just say visualize work.  That’s only the first step.  There are supposed to be other steps after that.  Right?

Aren’t there?

This is where, for me, we start to run into issues.  I’m not being theoretical or cheeky here.  In my former organization, my team ran Scrum (-but) for 2.5 years; another nearby team made the decision from the executive level to implement “Lean-Kanban” instead.  They expressly agreed with something I’ve heard Kanban proponents advance as a strength: unlike Scrum, they could adopt Kanban without changing any of their existing process.  (They seemed awfully excited about that.)

They got great, in-depth training (which they kindly invited me to sit in on).  The following week, huge Kanban boards went up to visualize their entire portfolio.  The first thing they “learned” (unnecessary quotes because everybody on the team already knew it) was that they were massively overloaded: at least three times more work underway than they could possibly complete on time.

When a 12-person team’s Kanban board fills all the walls, floor-to-ceiling, of a 40-seat conference room, it’s covered in 3×3 post-its, and each team member needs four to six laminated South Park avatars to identify all the work they’re doing at any one time, they don’t need a high-priced consultant to tell them where the dysfunction—sorry, “opportunity”—is.

And how’d they address the dysfunction?  As far as I know, they didn’t.

Why not?  Honestly, I don’t know.  Kanban calls for teams to limit work in process (WIP) and it’s a fairly obvious next step in this case, in some form.  I know they learned about limiting WIP, because I was in their training classes.  It was easy for my friends on the dev and BA teams to blame upper management and stakeholders for failing to act, but I don’t know if they really fought for WIP limits or just rolled over.  I’m certain no one at any level sought out or embraced the pain of significant change.

A year and a half later, the Kanban-wallpaper was still up, and the team still said they were “doing Kanban”.  At a local Lean-Kanban conference, I got a chance to sit down with some of them during a break and asked how the process was going for them.

“It’d be fine if the BAs would quit dragging us developers into their ATDD meetings.  It takes up all our time and we can’t get enough code written.”

“Hey!  What do you expect when you’re so slow delivering code that we have nothing to UAT?  We don’t have anything else to do but work on future requirements.”

I gather that they still haven’t implemented WIP limits, at least not properly, and they’re not managing their queues in or out.  We’re sitting at a Kanban conference and these attendees are still near the point of food fighting because they’ve decided the dysfunction is each other instead of their process.

And that’s why I think the Underpants Gnomes are not just a one-liner in Kanban, but a real risk that should be taken seriously and planned for.  What happens when…

  • the team doesn’t know how to find the root cause of a dysfunction?
  • the team can’t agree on what the dysfunctions even are?
  • the team identifies a dysfunction, but doesn’t know how to solve it?
  • the team tries to solve a dysfunction but just replaces it with another?
  • the team’s organizational culture doesn’t support problem-solving?
  • the team isn’t empowered to make the changes they think are needed?

A team full of highly motivated problem-solvers with great communication and teamwork skills will probably get good results with Kanban, but honestly aren’t they all too busy building carbon-nanotube space elevators while curing cancer?  Or writing the book on process improvement?  Seriously, teams that natively possess awesome diagnosis and problem-solving skills, are they even having this conversation?

... and it's a Big Visible Display, too!

The rest of us need to pay attention to the Underpants Gnomes when we’re getting started in Kanban.

What’s your plan for Phase 2? Can you do it on your own or do you need help getting there?

Note: if you are/were on the team I’m talking about and I’ve gotten any of the story wrong, please send me additions or corrections or perspectives so I can update!

Getting Personal with LIVE Events at the Microsoft Store

Come to the Microsoft Store in Bellevue and let me talk at you about ALM.

It’s impossible for me to talk about our new Coffee Talk LIVE series without also mentioning how much I love my little brother.  He’s been in retail management about as long as I’ve been in IT, and he’s really (objectively, I swear) good at it.  So last fall when he joined the team of the soon-to-be-opening flagship Microsoft Store in Bellevue, I knew they’d picked a winner and I hoped he had, too.

(I’m still getting used to the fact that he’s got a blue badge and a address and I don’t.)

I loved learning all about the Store from an insider’s view.  I turned out for the festivities on that crazy opening night in November, with Dave Matthews playing outside the front doors and the mall overrun with geeks.  You definitely don’t see that every day.  My house filled up with handy, reusable Microsoft Store shopping bags in all four colors.

The day I had my job interview with Northwest Cadence, I swung by the Store afterwards.  My brother was just getting off-shift, and he let me decompress over sangrias at the Bellevue Azteca.  (Don’t judge.)  Then I waited, and waited, and waited for things at NWC to settle down long enough for them to call back and—by then, honestly, unexpectedly—offer me a position.

Fast-forward just a bit to my first assignments here at Northwest Cadence: delivering our ALM Catalyst series of webcasts on a variety of Visual Studio 2010 topics.  Perhaps some of you reading this newsletter heard some of my sessions.  Hi!  How’d I do?  Studying up for the series was tough, since so many of the topics are new to me.  I’m grateful for the support of the team who helped me prep, shadowed my sessions, and helped me field questions!  I’m starting to get the hang of things now, and I’ve also taken on some of our biweekly Coffee Talks focusing on process and Agility.

But, from the beginning, one of the key things that frustrated me about the webcasts was the one-way nature of the LiveMeeting format.  Even with audio and a phone conference line, I find it really limiting that I can’t see any of you.  Are you nodding in agreement or furrowing your brows because I’m not making any sense?  Am I going too fast?  Too slow?  Is the content too advanced or too basic or just right?  Where should I skim over because it’s no use to you, and where should I dive deeper because you’re eager to know more?  Here I am teaching about awesome tools and techniques to get real-time feedback on your software development processes so you can make a better product… but I’m stuck with waterfall content delivery and a QA feedback cycle that doesn’t start until after I’ve deployed myself to production!  That won’t do!

And that’s when it hit me.  The Microsoft Store has a theater space!  Non-profit organizations and small businesses can sign up to use it for their events at no charge; my brother had told me about a “girls in technology” event series that one of his colleagues helped organize.  There’s no requirement to tie in with Microsoft products, but I figured the fact that we’re a Microsoft Gold Certified ALM Partner talking about their developer tools would make it an even better fit.  The store is bright and engaging and fun, just like Northwest Cadence.  Why not put on some of our events there?

My brother put me in touch with their Community Engagement Manager, and we confirmed that the Store is a perfect place for exactly what we had in mind: Coffee Talk LIVE, an all-NEW series of highly engaging, highly interactive sessions covering a variety of ALM topics.  We’re creating all new content for this series, so even if you’ve attended our webcasts before, we hope we’ll be able to show you something new.

As the name suggests, we’ll serve coffee, and we’ll do live demonstrations of Visual Studio features on the theater’s big screen.  You, yes you, can interrupt us with questions any time.  If we catch you yawning, we’ll either offer you a refill or open up for group discussion or otherwise re-focus the content so you always get something fresh and relevant to you.  We’ll have special giveaways and door prizes to make it even more fun, and when we’re finished you’ll have plenty of time to get to the office, or stay a little longer and play in the Store before it opens!  There’s Xbox, Kinect, Surface, Windows Phone demos on the giant video wall, and lots more.

Real coffee and real ALM talk at the Bellevue Microsoft Store on October 13

I’m really excited about this new series, and I’m thrilled that Northwest Cadence picked up my little idea and ran with it so thoroughly!  We did a dry-run of sorts this week, and four intrepid early-risers joined us at the Store for a totally customized presentation on Visual Studio and, as it turned out, Scrum, with lots of Q&A.  Just what we were going for!

At our next event, you’ll see the Bellevue debut of my new extended presentation on Test Professional, heretofore given only in Tempe, Arizona (my roadshow event last week) and as a webcast that I did for just one company in Florida.  It’s 90 minutes of serious hands-on testing techniques from manual to automated, tester to developer, with just the right amount of soapbox thrown in.  I promise to live up to the new Coffee Talk LIVE tagline: “Less Deck, More Demo”.

Register here for Testers Get Professional on Thursday, October 27 at the Microsoft Store in Bellevue.  50% off if you enter discount code earlybird before Friday, October 21!

Now that my little brother’s been promoted and relocated to help open the new Microsoft Store in Santa Clara, I won’t be able to use these events as an excuse to hang out with him… unless y’all show up in droves and make it a huge success and I get to take it on the road…!  Either way, hope to see you there!

Agile Project Planning: The Cake Is a Lie

We cling to old-fashioned long-term plans because they are familiar and we think they provide certainty, but they don’t.    We shouldn’t sabotage Agile by trying to bolt on a (dishonest) long-term plan; we should understand and embrace what we’re getting in place of the plan.

I’m blogging this from 35,000 feet, almost entirely just because I can.  I’m coming home from two things I’ve wanted to do for a long, long time: [1] travel on business and [2] get paid to talk.  Yes, it was as good as I hoped!

Plus I got two states I needed!


After! (It is ON, North Dakota.)

Anyway, tomorrow I’m slated to deliver the inaugural session of our “Scrum-damentals” Coffee Talk (free! register at!) and I’m taking advantage of Alaska Airlines’ in-flight wi-fi to put my personal touches on an awesome slide deck created by our in-house Scrum Authority, Martin.  Scrum-damentals will cover common Scrum adoption challenges and the dreaded ScrumButs.  One of the Buts that Martin wrote up is the tendency to try to do long-range scope and release planning in spite of the Scrum directive to plan only the next 3-ish Sprints in any detail.

In fact, this is one of the clearest commonalities between Agile and Scrum.

And my former team did it.  I helped.

So why’s that bad?  We know upper management is often uncomfortable with Agile, and a little release planning is necessary to keep them happy, right?  What’s the problem?



When we succumb to pressure to project-plan, we’re giving upper management false hope.  We are lying to them.  We know it.  They probably know it, too.  We have absolutely no way of predicting accurately what we’re even going to attempt to deliver in a Sprint a year from now, much less what we’re going to accomplish in that Sprint.  It’s insulting to everyone’s intelligence to pretend otherwise.  And we, the team, participate in our own downfall when we play along.

In tomorrow’s Coffee Talk, I’ll cover some strategies we can use to push back against the demand for the plan.  Bottom line: we have to speak up and we have to educate our upper management about the benefits of Agile.  When they start to understand how much they gain by doing Agile honestly and transparently and fully, they’ll have a much easier time giving up the dream of the delicious cake.