Accidental credibility

It isn’t accidental at all. I just accidentally forget I have it. Sometimes I get reminded.

I don’t read work books. Never have. (I read a lot; not for work.)

It took Steve, my boss, voracious consumer of all information media (he still listens to podcasts!), whose photo should be in StrengthsFinder 2.0 under “Learner”, nearly two years to persuade me to read Getting Naked, our company’s raison d’incorporation. I finished it in about two hours, and it changed my life. I still don’t read work books.

Especially lately, this has caused me some consternation and discomfort when I show up at a client site (or Microsoft TechEd) to train and consult on enterprise agility. There’s always some smarty-pants in the group who reads work books. I don’t mean they heckle; they’re perfectly kind. But those innocent questions that expose that I have heard of such-and-such seminal work and I obviously don’t know what’s in it? Awkward.

And so, for example, I showed up at my latest client site to help tackle their problems with ineffective agile retrospectives. I brought a ziploc bag of Sharpies (hard to find in Europe for some reason), a stack of sticky notes, and a naïvely cheerful attitude. Imagine my dismay to find that several of the thought leaders in the organization were carrying around a book called Agile Retrospectives and wanted to know my thoughts on it. Oops. I’m pretty sure Steve has been trying to get me to look at that one.

In the true spirit of Getting Naked, I swallowed my pride and asked to borrow my client’s copy of Agile Retrospectives, and I read it poolside at my hotel overnight. Quick read, incredibly valuable insights, did I mention I don’t read work books?

Interestingly, when I skimmed some of the exercises in the book, I noticed that I’ve done and used several of them without knowing their names. Simple stuff that I hadn’t thought of as “exercises”, like having everyone write down their thoughts first in order to make sure the quiet ones get heard. It’s likely I picked them up from managers and colleagues—many of whom were surely Learners—and added them to my toolbox over the years.

This afternoon, as I departed my client’s office, the owner of Agile Retrospectives stopped by to thank us for our time with them, and because he’s awesome, to share some feedback. I didn’t expect what he said.

“The developers on our team, when they heard a consultant was coming to train them on agile, they were expecting—well, it seems like anybody can read four books and say they’re a consultant. But the books don’t take real life into account, and the books make everything sound so easy.

“You’re different. You have fifteen years’ experience as a programmer, and it shows. They were really surprised. You created a lot of trust, because they know that you know what you’re talking about.”

Praise doesn’t get any higher than that. Here I was preoccupied with embarrassment that my clients—many of whom are in fact Learners—might be judging me because they’re so much better-read than I. In reality, what I have to offer is so second-nature to me that I sometimes forget everybody else doesn’t have it or know it already.

I’m not saying I don’t need to read a bit more. I clearly do. But I’m never going to be voracious with the work books, and I’m always going to encounter clients who naturally read work-circles around me. What I realize now is, neither one of those is a bad thing. I have skills and knowledge that clients need me for, and I need their skills and knowledge, too. Those motivated Learners will be the ones to help keep enterprise agility going long after their consultant has moved on!

Our complementary strengths are what makes us a great team. It’s what I teach to them. Let’s see if I can teach it to myself. :)

I spoke at TechEd!

I'm speaking at TechEd Europe!

Pre-conference seminar #12, “Enterprise Agility Is Not an Oxymoron”, all day on the Monday, in Madrid, BY MYSELF. That’s right, no Steve-shaped security blanket.

The worst part about giving the same pre-con twice with different speakers is having to compare the (insanely competitive) speaker and session rankings afterward. The good news is, I did OK! by myself. Not amazingly great like we did together at North America, but genuinely OK!

If you’re interested in learning more about how I teach Enterprise Agility, check out my Events page for upcoming webcasts and live workshops, or contact Northwest Cadence to request one. Cheers!

Care and feeding of your T-shaped individuals

How do you make sure you’re rewarding, instead of punishing, your utility players for their versatility?

Managing variability is a key agile practice and it’s one where many teams stumble.  Some feel the pain in “story sizing” or “estimation”; teams doing timeboxed iterations may encounter it when they scramble to finish what they committed or struggle to interpret and apply their velocity metrics.

There’s also variability in work types and roles, whether that’s the balance of code vs. test or specific coding skillsets like data vs. business logic vs. UI.  I blogged about it a while back as How Flexible Should an Agile Team Be?  A preferred way of managing variability while still allowing the specialization and deep expertise teams need is to cultivate T-shaped skillsets: deep in a few areas, with meaningful breadth across a range of others.

This carries the implication that the T-shaped individuals on your cross-functional teams will cooperate, flex, and share workloads.  That’s the point.  That’s what you have them for.

It also implies that at least some of the time, your T-shaped individuals will be working in their areas of breadth rather than depth—what Myers-Briggs would call out-of-preference.

That’s where a lot of teams hit a wall.  It turns out, just because someone on your team can do something in their breadth areas doesn’t mean they want to.  Doesn’t mean they love it.  I think we need to handle this situation carefully.  T-shaped individuals can be quite valuable and we don’t want to burn them out or alienate them.

In talking through this challenge with my current customer, I came up with two things that any T-shaped individual needs to know when you’re asking them to work on something that isn’t their depth:

First, they need to know and believe that you don’t expect them to work in their out-of-preference zone forever, or even very often.  They need to see a light at the end of the tunnel.  If breadth work takes over the stuff they actually love doing, you’ll lose them, which sucks for everyone.  If you find it necessary to drag them out-of-preference too much of the time, your team has a resource problem which you should solve with HR.

Second, they need you to fully understand, appreciate, and accommodate the fact that they’ll be slower and less effective in their out-of-preference areas than an expert in those areas would be.  If you have perfectionists, this’ll drive them crazy: they’ll hate delivering less than the theoretical best, and they’ll need reassurance that their effort is not wasted.

What do you think?  Have I missed something that you look for from your management team?

Update 4th April: Thanks, commenters!  Y’all’ve got me thinking about another principle.  I assert that it is never possible for the team or management to dictate someone’s depth skills.  They have to love a thing in order to get to be any good at it.  And can the team define someone’s breadth skills for them?  They can try, but they probably shouldn’t.

When we talk about how valuable T-shaped individuals are, we mean people who have natural strengths and interests and are flexible in how they help out the team at any given time… not minions who get assigned crap work because “somebody’s got to do it”.  (If you’re a sincere T-shaped individual who’s getting all the crap work, you’re insanely undervaluing yourself.  Go update your résumé.)  On the flip side, if your team members refuse to do out-of-preference work, maybe they’re not T-shaped at all; maybe they’re one-trick ponies…

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.

Conclusion

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.