A3 Management and Stock Issues

There are zillions of ways to make an effective A3. I needed to find a way I could understand intuitively, so I could get past trying to figure out the technique and move quickly on to using it for actual hard problems.

This week, Steven introduced us to the A3 management system and specifically the A3 format for delivering recommendations to our customer.

This is based on a Lean book, Managing to Learn (one of many books Steven lugged all the way across the Atlantic not on his Kindle). The deal is, the A3 is a paper size (approx. USA 11×17), and there are two columns with particular formats for presenting the nature of the problem and the proposed recommendation to fix, in a concise and collaborative manner.

As I was struggling to understand the mountain of A3s (all different) that Steven had brought along as examples, I noticed a pattern to them that meant something to me:

  • Harms
  • Significance
  • Inherency
  • Plan
  • Solvency

The A3 fits the outline of a very old-school stock-issues high school policy debate case. Of which I’ve written more than a few. (Cool kids don’t debate this way anymore, I’m told.)

  • Harms: the problem
  • Significance: what is the extent of the problem, and what metrics can be used to assess it before and after?
  • Inherency: what structural or attitudinal factors are reinforcing or worsening the problem?
  • Plan: the recommendation
  • Solvency: how will the recommended action steps resolve the problem, and which metrics will be used to measure success?

And here’s what it might look like in practice:

  • Harms: four teams are developing working software, but their integration and stabilization phases are trainwrecks and they have all come to dread their merges.
  • Significance: Team A has burned a week of their latest two-week iteration just on merging. Many of Team A’s changes from their previous iteration were lost when Team C merged over the top of them, and this will take at least another week to fix. Meanwhile, Team C’s release, which seemed tested and ready, has been delayed by nearly a month fixing bugs discovered after merging.
  • Inherency: the root of the problem is team branches. All four teams are working on the same product, and following a similar release cadence. All four teams easily decompose their work into small increments of working software that they are able to test and release every few days at best, every two weeks at worst. Isolating the teams doesn’t benefit anyone, and has led to the bad habit of isolated test and last-minute merge. No one team or role has responsibility for post-integration testing. Teams can’t easily understand or resolve merge conflicts found after weeks of isolation, so instead they tend to delete the changes they don’t recognize. Minor repairs to their process (many tried and failed already) won’t solve the fundamental problem that needless isolation causes harms. Only a comprehensive new branching strategy will solve.
  • Plan: implement a branch by quality strategy whereby the four teams, who are, after all, all working on a single product which is ultimately totally integrated, do their primary development together in one Dev branch.
  • Solvency: combining team branches into one will actually eliminate most code conflicts, and make any remaining conflicts smaller, simpler, and quicker to resolve. Earlier integration will force a number of additional practice improvements they are currently avoiding, most especially teamwork and coordination upon each checkin. Bugs caused by integration can be detected earlier. The teams will experience pain at first, especially because they have limited automated testing and regression will place new demands on their testers, but it will expose better data about their specific testing priorities, leading to better fixes in the long term. Finally, the early and frequent integrations should instill a sense, currently missing and sorely needed, that they are ultimately all one product team and that their success is measured not by the achievements of any one sub-team but by the value of the finished product.

So there you are. If you were a traditional-style high school policy debater in the USA in the late 1980s and you now want to know a key Lean management practice… yeah, OK, I’m the only one, aren’t I? Well, I’m good to go now.

And that’s my message here. I’m geeking out a bit about my modest debater past, but the real takeaway here is that sometimes I let learning get in the way of my learning. My new A3 trick is probably sub-optimal in lots of ways, but it’s superior to the A3s I wasn’t going to write at all because I didn’t know how.

Vertical slices and SOA

Even the term “vertical slice”, a common stumbling block in agile adoption, kinda implies a large-scale n-tier application. Modern architectures and agile can play nicer together than that!

“Story sizing”, decomposition, vertical slice of functionality, Minimally Marketable Feature (MMF), Minimally Viable Feature (MVF), and my personal least-favorite, Potentially Shippable Product Increment (POS*). I think it’s the biggest hurdle for orgs moving from not-agile to agile. I think many other problems with initial adoption (estimation, timebox sizing) boil down to this one.

Every dev team I see trying to get started with this initially tries exactly the same wrong thing, usually because it’s how they’ve organized their work in their not-agile process before: they want to split things up by architectural layers, and build, let’s say, all of the database and then all of the business layer and then all of the UI.

Any time I see a sentence with “do all of… and then all of… and then all of…”, what’s that remind me of? Oh yeah: waterfall. There are reasons we devs cling to this in spite of ourselves. Maybe another post another day.

The thing is, “vertical slices” aren’t satisfying either. Every single team I’ve worked with resists and/or struggles with this for basically the same reason: the users asked us for an epic-sized feature because that’s what they want. They don’t want a slice of a feature, they want a feature. One of the cornerstones of agile is that we’re doing these short iterations in order to get feedback from users. That’s hard to do when they’re inherently unsatisfied with these ugly proto-features they don’t want (and they’re deeply alarmed when someone calls them “potentially shippable”)!

I discovered an interesting thing at one of my customers recently, though. We struggled with “vertical slices” vs. Big Database Up Front for like two days, and only then did I find out how much they’ve worked to transition their legacy LOB apps into a SOA model: collections of beautifully loosely-coupled services and APIs with clean interfaces talking to each other to achieve some nice user-interfaced result.

Wow! This was exactly the hook I needed. Because what is a service or an API if not a neat encapsulation of a small logically-contained bit of functionality? I realized that even the term “vertical slice” implies a traditional n-tier architecture in kind of a large-scale sense. Today’s SOA (is that still what we call it?) has already broken down those giant tiers into little slices. The team didn’t even realize they were already doing it. Each service might have its own little n tiers, but on a much smaller scale. Small is exactly what we need!

My customer got stuck trying to decompose from the epic feature level, still thinking about all the little services they’d need to assemble (plus BDUF) in order to hook up a UI and show a “vertical slice” to the user. They didn’t see their services as value in themselves, but I think the value is right there. APIs don’t have a user interface, but, um, the “I” stands for “interface”. They encapsulate something someone finds useful, and they are independently testable. Better yet, they almost demand automated testing, a practice we already wanted to reinforce. Imagine: at the iteration review, sure, the team should demo UI mockups early and often to get feature-related feedback from users… but can’t they also “demo” individual APIs (that implement underlying business capabilities and algorithms that the users do care about) by reviewing the acceptance criteria for the service and showing off a suite of automated test results to prove that the logic works?

I guess my point is that, as it always has, agile practice goes hand-in-hand with what we know about how to architect high-quality, maintainable software. I was just pleased to understand this in a new (to me) way.

* j/k. But I do hate that term.

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.