Tuesday, October 28, 2014

Agility, Technical Leadership and the so-called Talent Shortage

My exposure to the agile community has not been super broad, but from what I have seen people tend to talk about agile in two forms.  Or at least I perceive two distinct discussions.  There is the "process" side of agile.  This includes things like planning, communication, team norms, managing deliverables, prioritization, etc.  Then there's what I call the technical practices side of agile.  This includes practices like continuous integration, test first development, automation, pairing, etc. - mostly those practices borne out of extreme programming (XP).

I'm a whole-hearted believer in these technical practices.  I believe it's these practices that form the foundation for agility.  You can do XP without the agile processes, but you can't be agile without XP.  Even doing XP in a pure waterfall world would yield huge productivity gains.  For that reason I mostly equate one's agility with one's strength in technical practices.  That's not to say there aren't significant gains to be had with process change.  You just can't get functionality in the hands of customers faster than you can build, test, and release it.  And the speed of your build, test, and release cycle is equivalent to how much of it you've automated.

A few years ago Andy Singleton posted Tech Leads Will Rule the World.  I've had it bookmarked ever since.  I liked what it had to say then.  I firmly believe it now.  Businesses are desperately fighting for agility as competition continues to increase and as software disrupts our world.  To achieve the kind of agility that is so critical now and for future business viability, technical practices could not be more important.

When it comes to adopting technical practices there is no one more important than tech leads.  These are the key influencers with the ability to set team norms, and most importantly, the ability to lead by example.  The only way to successful adoption is strong technical leadership.  The quickest way to peril is poor technical leadership.

But how do we all get there?  Especially with all this talk of the technical talent shortage.  Andrew Clay Shafer has taken a strong position on this topic.  He's well worth listening to.  Yes, we need to attract great talent.  First and foremost we need to look internally and treasure the strong technical leadership that we have today.  Your tech leads have a profound impact on the culture of the teams with which they work.

Do you know where your true tech leads are today?  If you're not sure look no further than your highest performing teams (they'll have the best technical practices).  And your "tech leads", well, you know how to identify them now too.

Friday, October 24, 2014

DevOps is Blue Ocean

I am fortunate to have recently attended the inaugural DevOps Enterprise Summit (DOES).  The event consisted of ~600 tech professionals from around the world.  It had an aspect to it that I really liked.  The event was not all about rockstar, industry-leading companies and professionals telling their stories.  Many presenters were and are change agents and leaders from larger companies with slower-to-change cultures.  This resulted in a unique, and fantastic conference.

On my way to the conference I decided to read a book that was given to me over a year ago – one that I had not yet prioritized high enough to read.  I’m glad I adjusted my backlog.  The book is called Blue Ocean Strategy and was published in 2005, so I’m a bit behind.  The premise of the book is basically this:

Companies spend most of their time competing in “red oceans”.  Red oceans are where the blood is.  The market is very competitive, profit margins have been driven down, and in order to remain competitive you have to scale.  The book advocates looking for and executing blue ocean strategies.  Blue oceans are where there is a gap in the competition.  There aren’t the same competitive challenges, and therefore the opportunity for massive growth still exists.  This may seem obvious, but the implementation is often not.

It’s easiest to illustrate with an example.  The first one in the book is about Cirque de Soleil.  Traditional circuses compete on a variety of characteristics that include (I’m sure I’m missing some):  price, use of animals, venue, aisle concessions, and number of simultaneous acts.  Price is low, animals are used frequently, venue is unimportant, aisle concessions help with revenue, and multiple simultaneous acts is considered important.  Cirque took these characteristics, eliminated some, reduced some, increased others, and added new ones, creating a whole new model.  They positioned their offering as a theater-going experience, allowing for a higher price.  They were able to do this by changing the venue, making it a higher end experience.  To align with the environment change they ditched the aisle concessions, but the revenue loss was more than offset by cost reductions.  Animal use in the circus makes some people uncomfortable anyway, and is often the most expensive part of the traditional circus.  They eliminated this all together.  And rather than put on multiple costly acts at once, which tends to overstimulate the audience and increase costs, they stuck to one.

You may have observed that with the changes Cirque made they actually increased revenue and reduced costs at the same time.  This is a primary goal in Blue Ocean Strategy.  And something we can and should endeavor to do outside of pure business ventures.  We should seek out win-win opportunities in the way we do our work too.

Typical infrastructure / operations management, over time, becomes a liability in most companies.  There is no better way to understand this than to read The Phoenix Project.  Or to ask someone who has worked in the pure Ops space (i.e. no DevOps).  At the conference Gene Kim shared the remarks of a colleague:



Support work is through the roof.  There is little (or no) time for long-term value-add work.  And the quality of life is terrible.  So from a business perspective you have high costs, low throughput, and low employee engagement. 

DevOps is the blue ocean.  By collaborating, and applying engineering practices to infrastructure management we can simultaneously achieve low costs, high throughput, and high employee engagement.  How often do businesses find opportunities like this?


So let’s get moving in the right direction.  Many companies are well on their way.  I was blown away to discover that one area within the Department of Homeland Security is deploying to the cloud with solid DevOps practices.  There is some great starter information in the 2014 State of DevOps Report, including business justifications and practices that result in better business outcomes.