8 November 2013

"A" Players

I hear many references to organizations wanting to follow the advice of Steve Jobs and to have only what he called "A Players". Jobs' logic was that when you have enough A players, they will discover that they really like working together and won't want to work with B and C players anymore. This has the effect of creating a great organization.

What's lost in that "sound bite" is that Jobs' went on to flesh out that notion that A players can come from many backgrounds, bringing talents from many different disciplines. Essentially, his idea was that you can't be successful with people who are only talented in one aspect of delivering a product, e.g. writing software.

As I write this post, there's a very interesting example of this playing itself out in the sporting world.  I'm a big hockey fan (Canadian, eh!) and love my hometown Ottawa Senators. They had a successful season last year, making it to the second round of the playoffs and earning their coach Paul Maclean the award for the best coach in the league. This year, however, they started off the season by struggling defensively which was an aspect of their game at which they excelled last year.

So, the Senators called up Mark Borowiecki from their AHL team in Binghamton, NY. Borowiecki is not an A player by the standards of many people. He's not flashy.  He doesn't score much, although he did score his first NHL goal in a game on Nov. 8th. He plays what's called a "simple game", meaning that he doesn't try to carry the puck but rather passes it. If he's pressured, he'll make a simple play off the boards or glass to get the puck out of danger. He was called up because he's considered a steady, calming influence. He's playing with other defencemen who are making several times the salary.

Since Borowiecki arrived, the Senators have won 2 games handily and lost the other in a shootout after overtime, still gaining a point in the standings. The team's defence has improved greatly, with the number of shots against them dropping dramatically since Borowiecki's arrival.

Is this a coincidence? Possibly. However I would suggest that Borowiecki's play has rubbed off on others. Also, the confidence that the coaching staff has shown in him by playing Borowiecki ahead of two more experienced and arguably more talented players also makes it clear to everyone that you will be held accountable for your play.

So, a "B Player" by most definitions has changed the way a whole team is playing.

The question, though, is whether Borowiecki really a B player? While in Binghamton, he had no goals or assists through 9 games of the 2013-2014 season, but he was the team captain. Evidently the coaching staff sees more than just his talent as being important. Perhaps what makes him an A player is not his talent for scoring but rather the intangibles he brings such as quiet leadership and a steadying influence on the ice.

While all of this is sports-related, I have certainly seen these concepts transfer to any domain in which people are working in groups with a common goal. They key to successfully working together isn't to have A players whose talent only represents a single dimension, but rather to have A level talent from multiple dimensions and multiple people.

In the realm of delivering software-based products, this means that those A-level talents are much more than just the ability to write software. You need people with the ability to identify and understand what the market for the product wants and/or needs. You need people who can create amazing, intuitive designs. You do need talented software developers, but complemented by people with talents for ensuring that the software works as expected and also continues to work then the unexpected happens. You need people who can understand how the raw data that a system creates can be used to inform business decisions. You need people who can understand how all of this needs to work without compromising the security of that data. You need people who understand how all of this works at the level of machines running anywhere from someones laptop, tablet or phone to servers running in a cloud environment.

If you only have A Players in one of those dimensions, you likely won't succeed. If you measure whether someone is an A Player within a dimension by a single metric, you may also miss the non-linear positive effects that a person can have. You might miss the Mark Borowiecki's who can raise the level of play of an entire team despite having much less talent than others by most of the common measurements.

1 October 2013

Sick, Not Weak

This is a little off the usual topics of my blog, but I felt that it's worth posting. Besides, it's my blog and I get to choose what goes in it! :)

Each Friday afternoon my employer, Shopify, has some event that brings the company together in our Lounge.  Last Friday we had a couple of demos and I did a talk about mental illness called "Sick, Not Weak", from the term coined by Michael Landsberg.

Here is a video of that talk.

Please share this video - it's a truly important message that needs to be heard.

Thank you.

13 September 2013

Surface Tension

Some religions consider walking on water to be a sign of divinity, but for bugs such as the
Water Strider it's simply how they live every day. How is that possible when the density of the water strider is greater than the density of water, i.e. it shouldn't float? It's due to a simple physical property of liquids, surface tension, which is the result of how the molecules in a liquid at its outside surface have stronger bonds to one another. This is a very distinct and measurable property of a liquid, and water has one of the highest levels of surface tension.

The water strider also cheats a little. They have several adaptations such as hairs on their legs that increase the area in contact with the surface of the water which reduce the force they're exerting on any given point. These are effectively snowshoes for water!

At some point, though, all the adaptations simply can't avoid physics and the force due to gravity will overcome the resistance due to surface tension.  When this occurs the item in question doesn't sink just a little bit into the water in some proportion to its weight, it simply sinks.

It occurred to me recently that our efforts to scale software development processes experience the same sudden loss of surface tension and related sinking.

When the group building a software product is tiny, for example the classic 1 to 4 person startup, they can simply float on the surface due to the very low weight of the process required to work. The group communicates effortlessly in an informal manner, and they're focused on shipping features quickly to satisfy their customers.

If the market for the product increases and the group grows to accommodate the increased need for features, the process needs increase as well due to increased communication paths. At this point the process has become more dense than the water, but it's still light enough that surface tension is sufficient to keep it above water. This is represented by small teams of 5-20 people using processes such as XP and Crystal Clear. Adaptations analogous to the hairs on the water strider's legs may allow the teams to cheat against surface tension and grow as far as perhaps 50 people. This would encompass Industrial XP and the Crystal Series of processes.

There comes a point, though, where the force exerted by the weight of the process overcomes surface tension, and the team sinks rapidly. The simple adaptations made to allow the simple processes to scale can't be applied anymore because a finite limit of physics has been reached. Cheating with practices like Scrum of Scrums, group iteration & release planning, and group retrospectives doesn't work anymore.

Essentially, you've reached a point where you need to create a vessel that has enough buoyancy to float
on the water to support the size of your group. The larger the group, the larger the vessel and the more effort required to actually operate and maintain the vessel. Scale far enough and you'll require a full-crew!  We saw this with the Rational Unified Process (RUP) and with more recent processes such as Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe) and even Spotify's Agile scaling model.

So what can we learn from this?

First and foremost, I defer to Martin Fowler's decade-old assertion that Scaling XP is the Last Thing You Should Do. Ask the question, do you really and truly need a large team working on a product? If your answer is yes, then ask why. If you still think a large team is needed, ask why again. Can you get away with a group working in startup mode? Does increasing the team size to the point that surface tension still holds you above water also increase the rate at which the team can deliver running, tested features? Are you scaling simply because the problem (or more correctly, the perceived solution) seems large?

What can we learn from the nimble water strider, gliding effortlessly across the surface of a pond? Perhaps we're too quick to jump at the solution of increasing team size and thus increasing the weight of our delivery process. How long does it take before we realize that we aren't gliding on surface anymore, but instead have sunk?

In the end, the trick is to identify when you need a water strider instead of an aircraft carrier, and vice versa. I would suggest that the number of times you need the latter is minuscule compared to the number of times that the former is the more effective approach.

29 August 2013

A Pain Problem

A while back I had an experience that's the closest a male will get to giving birth - passing a kidney stone. Suffice to say, it wasn't much fun. I did learn something interesting from the experience,  though - morphine is wonderful. I didn't encounter any of the common side effects such as itching, and it was a VERY pleasant feeling. The pain disappeared completely and for a few hours I totally understood Keith Richards. I also had no difficulty seeing how people become addicted to opiates.

When it was still on the air, I used to watch the TV show House, which was about a brilliant doctor who specializes in diagnostic medicine. He and his team determine what's really wrong with patients when others haven't been able to figure it out. There was a lot to like about House's approach in that the solution to the riddle of an illness was never the result of one person's insight alone, but rather a group effort leveraging the talents and knowledge of each individual. House himself, though, was a classic anti-hero - abrasive, and seemingly without feelings for anyone. He also had a problem.

His character had experienced an aneurysm in his leg which led to surgery that left him in constant pain. House self-medicated with Vicodin to deal with it, and gradually became addicted to the pain killer. In one episode he was confronted and told he had a "pain management problem", which was a euphemism for being hooked on Vicodin. House's response was, "I don't have a pain management problem, I have a pain problem!"

This was a brilliantly simple expression of his ability to look beyond mere symptoms for an underlying cause. If the chronic leg pain was eliminated there would be no need for the Vicodin, addiction notwithstanding.

In the way we work in the software industry, we often experience "pain management problems". The rush of adrenaline we experience when working long hours and pulling all-nighters to meet a deadline, for example, is highly addictive. Like my experience with morphine, I've been there and the exhilaration temporarily makes the exhaustion bearable. Whether it's just your immediate peers who know or the whole world, the pats on the back and the satisfaction the comes with pulling it off have a huge effect on us.  Way to go, Dave - you're the ultimate team player!  We couldn't have done it without you!

In an emergency situation, such as when your system is down and the phones are ringing off the hook, this kind of response is entirely appropriate. In House, patients weren't immediately sent to the diagnostic group, they had been examined and treated using the normal processes first. The patient was  stabilized before digging for the real cause of the illness.

In day to day work, though, the adrenaline rush can create a "pain management problem". House eventually became so dependent on Vicodin that he lost his medical license, spent time in a psychiatric hospital, and broke the law. In building software systems this way, we make mistakes, cut corners, get sloppy and become burned out. The code we produce is of lower quality, and we don't deal with technical debt because we're busy trying to find our next hit of Vicodin. In the end, we and the consumers of our work suffer. Our addiction hurts ourselves, the people we work with, our families and the people using our software.

So how do we deal with the "pain problem" vs. the "pain management problem"? As cheesy as this sounds, the first step is admitting that there's a problem and that we need help. We can simply go cold turkey and refuse to work the crazy hours, but if others are expecting the adrenaline-fueled level of work then that approach won't necessarily fly.

There has to be a system-level effort to deal with the problem and the first place to start is to stop rewarding people for demonstrating the behaviour. While heroics are sometimes necessary, they aren't a sustainable way to deliver software. That said, I totally understand that there are days when you reach a flow state and can work 12 or 14 ridiculously productive hours, but those need to be balanced with time spent not working. Disengagement even for short periods is the biggest step towards "cleaning up".  When that extraordinary effort becomes ordinary and expected, the pain management problem has started.

We also need to dispense with the notion that aggressive schedules will focus people on the goal and make miracles happen. How much pain has been created by that idea alone? Good product management includes understanding how little can be shipped that will delight your customers. It also means listening to the development team when they say that a deadline isn't realistic, which in turn means the development team has to be honest about their perception of how long something will take to be built.  Even a high-level gut feel is a pretty good indication when the people have experience in the domain and with the tooling.  Dan North wrote about that in Blink Estimation.

There must be a truly shared understanding of business problem that's being solved and a cooperative, collaborative relationship while a solution is being built. Hearing statements like, "We have to have this feature to be able to ship!", a couple of weeks before the end of a year-long project indicates that this isn't happening, and puts you in the express lane of the road to the pain management problem. Effective feature slicing is a skill that must be learned not only by the product people but developers as well in order to be able to ship without pressure. Jeff Patton's Story Mapping is a tremendously useful practice for this.

From the developer's perspective, you have to say no when these demands are made which implies that you have to feel safe to say no. The demands are often portrayed as emergencies, but when you have multiple emergencies a week for months before shipping where's the real problem? Saying no is an initial big step towards breaking the addiction, and it something I've written about in the past.

Finally, we need determine how everyone involved in system delivery can learn from their collective experience in order to prevent the need for "crunch mode", "stabilization sprints", "all-nighters" and other symptoms of this problem. While House was a brilliant diagnostician, there was never a situation where he alone solved a case. It was always a team effort, with a small insight from one person leading to a cascade of ideas from others. So, leverage the wisdom and experience of everyone involved to provide those insights. A developer intern might come up with something that leads the group to see a whole new way to ship something that customers have been yelling about for ages. A product manager might have an idea for a simpler approach to a feature which triggers the developers to find a way to build a feature in a day rather than a few weeks. We don't know when and if those moments will happen, but if the whole group is working together and shares the same understanding of the goal then the probability of an occurrence is much higher.

After my kidney stone experience, I was given a prescription for about 20 morphine tablets. I used one when I passed another stone a couple of days after the first, but I never took another one. I increased my fluid intake, adjusted my diet to reduce the amount of oxalates - the stuff of which one type of kidney stone is made - and increased my intake of citrates which helps prevent the formation of stones. Rather than develop a pain management problem by popping morphine every time I had a stone, I dealt with the pain problem by obviating the need for the morphine.

How, in your software delivery world, will you deal with the pain problem rather than creating a pain management problem?

27 August 2013


Recently on Twitter I was part of a conversation about how software developers become locked into their tools to the point of religious fanaticism.  Now, don't get me wrong - good tools make developers more effective, and the extent to which developers learn how to work effectively with their tools amplifies that.

What strikes me as odd, though, is that we work in an industry in which change isn't just normal, it's expected.  The rate of change continually increases, and shows no signs of abating anytime soon.  This is odd because developers seem so unwilling to consider changing their tools.

My perspective on that may be skewed by the fact that I spent a good deal of my career as a contract developer.  Usually I walked into a new gig and was shown to the machine I would use, told which development environment the team used, the source control system, etc.  I simply had no say in the matter.  I had to adapt, or I could find a new contract.  I can say, unequivocally, that I never left a contract because of the tools used.

Here's a quick breakdown of the environments in which I've worked since I first started writing code:

30 Years Ago (1983)

  • Command line on an Apple ][, writing BASIC and assembly code
  • Very few editing features, but ignorance was bliss
  • A year later at university it was sed or a similar editor on the school's mainframe writing FORTRAN

25 Years Ago

  • xedit on an IBM mainframe with REXX
  • it was a decent full-screen editor which could actually be automated to provide full-screen UI's for mainframe apps
  • I also used vi on Unix for a number of things, which felt very clunky and backward compared to xedit

20 Years Ago

  • Used the editor from Microsoft C for, not surprisingly, C as well as a couple of other languages
  • The editor was very 'comfortable' to use and I became quite familiar with it

15 Years Ago

  • Worked within the Powerbuilder, Visual C++ and Visual Basic IDE's
  • It wasn't efficient to edit outside of those tools, and indeed was somewhat risky
  • Became comfortable & proficient with all of them
  • The IDE editors were good enough to get work done
  • Also used vi when running remote shells on Unix systems

10 Years Ago

  • Various Java IDE's - PowerJ, JBuilder, Eclipse depending on the standard at the client's site
  • Executed tests within the IDE
  • Used Textpad for text editing outside of the IDE
  • Used vi when in terminal mode on a remote host

5 Years Ago

  • Used Eclipse and NetBeans for Java, Visual Studio for C#
  • Executed tests from the IDE
  • Used Textpad for other text editing
  • Used vi when in terminal mode on a remote host

Today (2013)

  • Sublime Text 2 for both text and code editing
  • Execute tests from the command line
  • vi when in terminal mode on a remote host

What's interesting about the last entry is that I feel like I've lost some of the features that I liked in the IDE's I used going back 15 years.

Sublime Text is really, really fast at indexing and searching through the text in thousands of files, but that pales in comparison with the ability to find the definition of a method in Eclipse, or to traverse a class hierarchy.  I can write macros in Sublime that will automate repetitive operations, which I liked in Textpad and sorely missed in the IDE's, but I don't have the automated refactorings that are available in Eclipse and NetBeans.  I currently work in the Ruby/Rails world, and gave RubyMine a try - it simply choked on the size of the code base I threw at it, and just wasn't viable in this context.  So, all searches and refactoring efforts are manual.

When I observe developers working in vim and emacs, I feel like I'm watching a virtuoso performance by a pianist - they make it look so effortless!  That's fantastic, and these developers do work very quickly in those tools.  What strikes me, though, is that it appears that those tools are optimized for writing code, and less so for exploring and refactoring.

The mere suggestion that developers look at using a tool different than the likes of vim and emacs requires a full body Nomex suit to protect one from the flames that will ensue.  However, my experience has been that it's actually not that difficult to adapt to new tools as they come along.  It does take some time, learning and un-learning but the flexibility is worth it in the end.

After all, it isn't the strongest or fastest or even the most intelligent species that survive - it's those which are the most adaptable to change.