Jim Harrer


3 tips to start your DevOps program within your Information Technology (IT) Department


What is DevOps?

DevOps is a software development framework that stresses communication, collaboration, integration, automation, and measurement of cooperation between software developers and other IT professionals, (including Product Managers/Product Owners, IT Operations, IT Infrastructure, Enterprise QA, Release Management and Change Advisory Board). The framework acknowledges and supports the interdependence of software development, quality assurance, and IT operations, and aims to help an organization rapidly produce software products and services and to improve application performance in production.

The evolution of DevOps.

Many IT organizations do not have a formal DevOps program in place today, however a 2014 CIO survey stated 88% of CIO have it on their roadmap, up from 66% in 2013. The concept was first introduced back in 2009 as the Agile Software Development methods began to mature and evolve. DevOps was born out of the need to study the hand-off between software development and IT operations.  In order for development teams to get in a consistent production release cadence, Agile leaders quickly learned IT operations would need to be become part of the “agile team”.  However, anyone who has worked in IT understands, there is a natural friction between developers and operations.  It won’t surprise you that most developers find the deploying of software outside their job duties and IT operations will likely tell you developers are sloppy with their handoff, often leaving out critical deployment instructions or configuration changes.  Yet, when it doesn't work in a lab outside of Dev, it often requires both teams to figure it out - causing even more frustration within these teams.

A successful DevOps program will strengthen the relationship between development and operations, giving them a common goal: Delivering quality software, faster, as one team!

Here are 3 tips to help you get your DevOps program off the ground.

#1 – Create a DevOps cross functional “Team”.

Break down walls between development and operations by creating a DevOps “Team”.  Similar to scrum teams, a DevOps team starts better when they’re able to self organize. Being a members of the DevOps Team is a part time team activity, we don’t want to create another silo by removing them from their functional teams. These members come together each week to meet and collaborate, then go back to their functional teams. However, just like with any team, it’s best it if has a captain and a coach.  There are two ways to approach this, one way is to have co-captains and co-coaches, ideally one from development and one from operations who share the responsibility. The second approach is to assign a Captain and Coach from one group.  If this is the way you want to go, I would suggest the IT Infrastructure team take lead, simply for no other reason than they’re usually “accountable” for anything in production, so having them lead the program will give it a better chance for success.

Rate this blog entry:
Continue reading
4670 Hits

The Lean Start-up MVP – One size does not fit all.

Eric Ries’s bestseller, The Lean Startup, is a thoughtful book that has created a conversation about startups.  It focuses on how to go from the back of the napkin to a Minimum Viable Product (MVP), to get in front of prospects in order to see if the idea is viable.

As with any new methodology, framework or process for the matter, I do not think audiences can truly measure its viability until they practice it themselves and spend time teaching it to others.
Lean-Startup-MVPI’ve had the chance to do both, use it with a couple of startups I’m involved in and teach it in the VentureBox business accelerator in Bend, Oregon.

The key principle of The Lean Startup is BUILD-MEASURE-LEARN.  The goal is to come up with a minimal feature set, bring it to market, measure actionable metrics and finally learn from the experience and then start again.  It barrows heavily from agile software development and favors learning from early adopters versus relying deeply on requirements management by someone in marketing.

I’m all for Build-Measure-Learn, what I have a problem with is Minimum Viable Product (MVP).   What is the definition of “Minimum”? I’ve witnessed entrepreneurs get so caught up in this MVP concept, that they test a product too soon and pivot based on incomplete data.  In my opinion, more time, not less, needs to be spent defining the MVP, including who the audience is that will see it, at each iteration.  Don't make the mistake of thinking the MVP is outside of the product lifecycle. 
MVPs should be matched to audiences. For example, your first MVP may be designed to only been seen by the development team, then management, then marketing and then prospects under NDA.  My point here is, be thoughtful about the process and audience.  Showing it to management or marketing, can quickly throw the team off the rails.  An MVP has its own product lifecycle development process, some stages should only be viewed by the core team.

Keep in mind if you’re building hardware, versus software, you have more challenges because of soft tooling requirements.  Also, don’t under-estimate the power of look and feel.  Ignoring UX/UI in some applications can take you down a rat hole you didn't intend. Each product is different. Craigslist appealed to its audience with it's simplistic UI.  Instagram's UX/UI from the get-go is what helped it go viral. 

Rate this blog entry:
Continue reading
5409 Hits