Author: elvisboats

Short Version: I'm married to the amazing (and amazingly forgiving) Jennifer, proud possessor of two amazing kids, crazy about all things trouty with fly fishing. I'm an Application Development Manager with Microsoft, and am based out of Portland, Oregon. Long Version: I grew up in Oregon, and moved down to California with the original goal of finishing my education in Civil Engineering, but I found application development and RDBMS systems much more exciting! I do miss the mountain biking in California and the awesome Mexican food, but Oregon is my home and I have never regretted moving back to start a family. Plus it gives me more time for fly fishing for trout and steelhead on the beautiful Deschutes river in central Oregon! ;-) Working for Microsoft has by far been the best experience of my professional life; it's great working with a group of people that are passionate about writing good code and continually improving development practices and firepower. Past assignments have included Providence Health Plans, Kroger, and managing a .NET development team at Columbia Sportswear. Working at Columbia in particular gave me a great customer-side perspective on the advantages that Azure offers a fast-moving development team, the dos and don’ts of agile development/scrum, and the cool rich Ux experiences that SPAs (Single Page Applications) can offer with Breeze, OData, WebAPI, and modern Javascript libraries. Microsoft did a fantastic job of engaging with Columbia and understanding our background and needs; I witnessed their teams win over an initially hostile and change-averse culture. The end result was a very satisfying and mutually beneficial partnership that allowed Columbia to build dynamic applications and services using best-of-breed architecture. I’m a MCDBA and a Certified Scrum Master.

It’s not how hard you work – 3 essential tips for productivity.

A few months ago I was sitting in my garage, frustrated. It seems like every time I had to get ready for a fishing trip, I would have to go through dozens of boxes looking for gear. And I was always forgetting something important. Why is this so painful?, I thought, rummaging through another unlabeled box of mismatched junk, hoping not to end up with a rusty #4 hook embedded in the ball of my thumb.

It all came to a head on a river rafting trip last August. It’s OK, I told my friends at the launch, a raft is never full. But after we loaded everything on, I felt much less smug about things. The gear and boxes were piled up so that it teetered over my head at the back of the raft, nearly tipping it over, and the sides of the boat were barely above water. This was on a stretch of river that was known for having some truly frightening rapids, and as we gingerly eased ourselves into the raft, a small crowd gathered to watch the show. No one said anything as we paddled the wallowing boat out to midriver, and I remember one older gentleman taking off his hat. It was one of those trips where the best you can say at the end is, “Well, we survived.” The tipping point for me was when a family of four, with a dog, came by with one quarter the gear we had – floating high and dry while we barely stayed afloat. The father looks us over a little and kind of cocks his hat, and asked us when the garage sale was.

Getting home I refused to put any of the boxes back until I had gone through everything and separated out the essentials, and moved everything else out to Goodwill. Suddenly what was six boxes of miscellaneous and jumbled junk became one box. Hmmm, I thought. That’s interesting. Then I took my fly boxes – a mishmash of fur, hackles and hooks – and laid them out in order, as you see below, and took out anything that I’d bought on a whim that would never see a fish. Suddenly, my boat was a lot lighter –and I was spending a lot less time rummaging through gear and fly boxes every trip.

 

My flies all tied up and ready for a fun day on the river.

By not taking the time out to do a little tidying up and reorganizing, I was costing myself valuable time. I’ve found the same thing to be true at work. Time is a diminishing resource for most of us. For me to keep my head above water at work, I would need to learn how to focus on the important things and let the rest of the clutter slide. Below are three tips that I’ve used over the past six months that has dramatically increased my happiness and reduced stress. I hope you find it of value!

Tip #1 – Taming The Savage Inbox

How many times have you gotten into work excited – today is going to be a great day, I’ve got all these cool things to do – and decide, while your coffee is brewing, well, I guess I’d better check my email – and the next thing you know, it’s 10 a.m. and your daily slog of meetings is beginning, and you haven’t really gotten anything done? The biggest tyrant of our time by far – besides runaway meetings – is email, by a mile. If you’re not careful, you’ll be sucked into a reactive cycle of compulsively checking your email almost constantly. Your company is paying you to be productive – and responding to emails within minutes is NOT adding business value. With very few exceptions, emails can and should wait on the back burner so you can address them in a batch. Our goal should never be too have a “clean” inbox at the end of each day – but to as efficiently as possible pick out the emails that are truly important from the pack and knock them out quickly without allowing it to dominate your workday.

So do yourself a favor. Only check email the afternoon, never the morning – and turn off your email alerts. Set expectations with your customers and close partners that your SLA for emails is within one business day, and that for urgent issues they should call you. And take the time to identify that one special thing that you want to get done each day in advance – and don’t check your email until it’s done, finished, kaput. This one tip alone will quadruple your productivity and your work satisfaction level – and make you feel like the master, not the slave, of your own time.

Tip #2 – You Come First

As a team lead I was always running around every day, harried, stressed. I would look at some of my developers at the company gym, working out or hitting the treadmill, and think bitterly – I wish I had time for that. Over time though I noticed something – the developers who took the time out every day, usually in the morning, to exercise, go on a walk, have a healthy breakfast – they were consistently the top performers. Somehow, by putting themselves first and ignoring all the urgent deadlines and project pressures we had as a team, they were able to get more done than others like myself, slaving away at a hot keyboard for 10-12 hour days. So, I started to walk in the mornings, and took a few minutes to make a good healthy breakfast instead of that Egg McMuffin and a coffee to go. Guess what? I was happier – and midway through the walk I would often get clarity on how to solve a problem that was nagging me at work. Difficult things suddenly became easy. I lost weight and felt happy and healthier – and I got more done.

In the end you have to remember that, even for those lucky few of us that work for great companies – we may love our jobs, but they don’t love us. In the end work is a large but ultimately rather meaningless part of our life. It has to be kept in perspective. Put yourself first with a great morning ritual – a walk through a wooded area, a nice healthy breakfast and a shower, a few minutes to meditate or read. You’ll be amazed at how much more you get done when you treat yourself with compassion.

Tip #3 – Reflection

One of the best things I liked about Scrum and Agile techniques as a team lead is the opportunity to reflect a little. “What did we get done? What will we shoot for next? What could be improved?” We would write these up and email it to the team and partners – and I can’t even tell you how many mistakes this prevented me from repeating, and how much more on-target our development activities became.

To stay on course, first thing in the morning write down the three most important things that you want to do today. If it helps, put them on sticky notes on a whiteboard. (It always gives me a nifty little feeling of satisfaction when I rip one of them off the board and crumple it up.) In the evening, cover in a journal the three reflection points I mentioned above – “What did I get done today? What will I do tomorrow? What could have gone better?” I usually put this as a reminder in Outlook for me, as – if I don’t block out time for this meditation – it often gets crowded out. Spending a few minutes reflecting really helps me keep my focus on the important things that can slip away with the chaos of each workday.

Finishing Up

Shakespeare said:

“Life’s but a walking shadow, a poor player

That struts and frets his hour upon the stage

And then is heard no more. It is a tale

Told by an idiot, full of sound and fury,

Signifying nothing.”

 

For too many of us, sometimes our life becomes a little like that. There is a ticket out of that very frustrating and unproductive cycle though. You don’t have to do all of the suggestions above at once. Try one or two for a week or two – and if it works, keep it up. For all of us though, learning how to control interruptions like email, building a healthy morning routine, and spending a few minutes reflecting will help you feel more in control of your life – and perform better when it counts.

Just set up a HA linux cluster… like a BOSS! (JBoss, that is…)

Followed the incredibly easy startup guide from Keith Mayer, superstar – http://blogs.technet.com/b/keithmayer/archive/2014/10/03/quick-start-guide-building-highly-available-linux-servers-in-the-cloud-on-microsoft-azure.aspx

The Powerpoint deck is about 20 slides or so, incredibly easy to follow. But here’s a Cliff notes version for us Linux newbies out there:

  1. Log onto the Azure management portal. https://manage.windowsazure.com/ – the new one is fine.
  2. Create an Affinity Group (Settings -> Affinity Group). Call it something like LinuxForDemoDH or the like.
  3. Create a Storage Account. Click + (New), Create a Storage Account, then Data Services -> Storage -> Quick Create. Select your Affinity Group.
  4. Create a Virtual Network. (Network Services -> Virtual Network, Quick Create).
  5. Create a Cloud Service. (Compute, Cloud Service, Quick Create). Select your affinity group! I called this “linuxwebapp” in my example.
  6. Add a new VM from the Gallery.
    1. In this case I chose Ubuntu, Ubuntu Server 14.04 LTS.
    2. Called it “linuxwebapp01” but it really doesn’t matter since the frontend is set in #5 above.
    3. Uncheck the SSH key, and check Provide a password.
    4. Select your Cloud Service and your Virtual Network / Storage Account.
    5. Select the option to Create an Availability Set (call it Linuxwebapp or the like)
  7. Follow the above steps to add a second VM. Call it lxwebapp02 or the like. Only you won’t need 6e, just point to what you created then.
  8. Select your App01 VM and browse to the dashboard, then point to Endpoints and select + Add.
    1. Add a standalone Endpoint
    2. Call it HTTP – and select TCP | 80 |80.
    3. Select the option to create a load balanced set. Call it LB_HTTP.
  9. Follow the steps above for WebApp02, only hook up to an existing LB set.
  10. Look at the dashboard and note the name/port of the environment under the SSH DETAILS portion. Connect to it using a SSH client like bitvise, and use the azureuser account you specified last time. A Linux shell prompt will open. Enter the following: run sudo apt-get install apache2
  11. Follow the same steps on the second webserver.
  12. Now to test. Open up the App01 web server in Azure management portal and select the Dashboard, then look at the DNS name. Try to open it in a new browser window. If you can view the following, you’re golden!

That’s it for now. I’m going to try more automatic provisioning of my new highly available and scalable Linux webservers later today.

<news flash>Well I just got brought in on another firefighting task so my IAC (Infrastructure As Code) efforts will have to wait. See this post for the script I was going to follow: http://blogs.technet.com/b/keithmayer/archive/2014/12/01/step-by-step-automated-provisioning-for-linux-in-the-cloud-with-microsoft-azure-xplat-cli-json-and-node-js-part-2.aspx

 

 

 

 

 

 

Getting caught up in February… the Disapproval Matrix and public speaking tips

A few quick notes before I have to go…

And I love the Disapproval Matrix (otherwise known as the Quadrant of Criticism) here – although it contains salty language. http://annfriedman.com/post/49152967734/in-my-ongoing-quest-for-the-perfect-framework-for

Our initial reaction on receiving criticism is to 1) attach the critic or 2) retreat into a hole and say, “I stink and everything I’ve ever done is worthless!” Neither is a good reaction. Instead, like the Arabs say – “when you drink water, consider the source”. Consider if the person 1) knows you and 2) is rational. If they know you and are rational, they’re Friends. If they don’t know you and are rational, they’re Critics. Both are valuable and should be evaluated – we’re not perfect and course corrections are necessary in life. (Imagine a driver on the freeway that refused to never change course!) If they’re irrational and either know you or don’t – IGNORE THEM.

Saw a great article from a MSFT architect on public speaking. Here’s his tips:

  1. Think about presenting things in a new way or light.
  2. Start strong. You have 30-90 seconds or you’ll lose them.
  3. Have something to say. What’s your key point?
  4. Say it well.
  5. Stick the landing. (leave them with the 1 thing they need to hear.)
  6. Practice.
  7. Be yourself.
  8. Don’t let your audience steal your energy. Don’t look at that guy yawning in the fourth row for example.

DevOps – Cats and Dogs Living Together!

DevOps is a worthwhile investment to make. I think sometimes people hesitate, because it can be some time away from your regular duties to invest in new skills, to start doing test-driven development, to move your infrastructure over to a configuration management system like Puppet. But what I’ve found is, it’s really a worthwhile investment that not only improves the quality of what’s being built, but the job satisfaction of everyone who’s doing it. Bess Sadler, Digital Library Systems at Stanford University

Before a few months ago, I wasn’t sure what DevOps was in reality and I was a little suspicious of the term. Wasn’t ALM enough? I was kicking my bits out to QA every day using continuous integration – what did it matter if it took a few weeks more to get out the door to production? That’s the Ops people’s responsibility, not mine!

Without knowing it, I was stumbling up against a major shortcoming of ALM. Ken Schwaber said the purpose of Agile was to produce potentially releasable software as quickly as possible. And we took that and ran with it. I remember one project where we thought we made AMAZING progress when we kicked out a very robust and interactive survey site for our customers in only two sprints – getting it out the door to QA in record time. But what did that really mean for our customers, if it took Ops 10 weeks to build out the environments to support it on production? As devs, we failed to treat Operations and infrastructure as equal partners in the process – and we missed an opportunity that cost the business valuable time to market.

 

“To Heck With Them, I’ll Do It Myself” – the Rise of Shadow-IT

As a result of this friction, something called “Shadow-IT” has arisen over the past few years. If provisioning software can take weeks or months to implement, it makes any thought of Agile development a pipe dream. It’s become increasingly more easy for developers to build up VM’s and entire QA/PROD environments on the cloud. When a developer is faced with an apparently stubborn and slow-moving Ops organization, it’s understandable that some have made the decision to take on the job of building out production environments and doing an end-run around Operations.

There’s some psychology at work here. Fundamentally developers have a core set of values and a background that’s very different from Operations/IT. Developers are focused on agility – producing features as quickly as possible and getting them out the door. Devs are evaluated by their ability to produce, and produce quickly. Operations teams typically want to make a plan and execute to a plan – they are evaluated by their track record with stability and security. Stability and agility are on opposite sides of the spectrum, my friends.

As a developer I was hurting myself by not thinking more of the end goal. And put yourself in the shoes of that poor Ops guy that’s given an extensive manual setup script six days before launch. If that first war room deployment is a train wreck with lots of on-the-fly adjustments and long hours, how eager will they be to work with me in the future? This knocks CI right out of the picture, since they’ll think, “If I deploy more things faster to prod, won’t I be shooting myself in foot?”

It comes down to our definition of done. We aren’t done when it builds on our machine and we huck it over the fence. As software cratsmen, our job is to deliver value – and value is software running in production, period. So, for DevOps to work, it’s more than just RM or tooling. We as developers need to be more interested in the end product, and IT needs to be more interested in the beginning.

I believe the above attitude – which I have fallen into several times in my career – is very shortsighted. Operations and tracking down performance bugs or environmental anomalies is a specialized set of tasks – and one that I’m ill-suited for. I grit my teeth and walk through Perfmon logs when I have to – but it’s not a core skillset. Shadow-IT is NOT the answer in improving our time to market long term – and as we called out above, that return trip of information and feedback on usage is suddenly missing, crippling our development efforts.

DevOps Comes on the Scene

Back about six years ago, in 2009, a group of people noted that the shortened release cycle was causing a lot of friction – it exposed a gap between the people writing the software and those responsible for deploying it to production:

The old way of doing things with monthly and quarterly releases worked OK, but with daily releases with CI the Operations side of things is falling behind. Some key points exposed by the above graphic:

  1. We needed tooling to automate releases as much as possible – including tracing and approvals
  2. The old way of “it works on my machine” or being surprised when sites weren’t available – being told reactively with SCOM or worse by external customers – was a no-go.
  3. We were having problems closing the feedback loop – that’s the top part of the cycle. Especially with disconnected business owners, it was VITAL to receive as much specific metrics as possible – from Ops, from usage patterns on the app itself – so we’d know what features we needed to prioritize for the next sprint.

To fill the gaps, the concept that came to be known as DevOps came into focus:

Let’s break this down by People, Process and Tools:

  • People
    • Stronger collaboration not just with Ops teams but also QA, BA’s and end user community
    • Bugs are knocked down immediately not left to mounting technical debt
    • Stronger focus on continuous learning – versus unattainable “zero defect” or unproductive manual Change Board meetings
  • Process
    • Unit testing and functional/integration testing becomes a part of each release cycle.
    • Incident management feeds bugs back to dev team
    • Release branching simplified and feature branching verboten
  • Tools
    • Release management to handle moving bits out the door
    • Tools to handle provisioning of environments – infrastructure as code

As you can see, the assumption many people have when they hear the word “DevOps” – “Oh, that means RM” – isn’t anywhere close to complete. It’s like saying that ALM is having your code in source control. And the goal we have in mind isn’t some kind of unrealistic paradise where we are all around the campfire telling stories and roasting marshmallows. As I heard recently by an Agile architect, “DevOps does not mean Operations and Devs hugging each other”. What he meant was, the point was getting it out in production as quickly as possible – and getting as much metrics back as possible. It’s more about efficiency than it is about making friends.

So there’s a lot to that formal definition of DevOps – “The collaboration of IT Operations and developers in deploying new software to benefit the business.”

 

The Importance of Culture

So if you want to “be DevOps”, don’t create a separate team and don’t search for some magic process or methodology. …your operations team to start speaking up and working with your development team about what could be done to reduce the operational complexity of the software. Figure out how to make your software easier to configure, easier to deploy, and easier to operate in general. Likewise, your development teams need to seriously listen to the operations group. They need to treat the operations team’s concerns just like they would treat any end-user feature request or bug request. After all, your operations team is simply another type of user of the development team’s software. (from http://www.devopsonwindows.com/it-takes-dev-and-ops-to-make-devops/ )

Changing culture is hard. For many developers, their individual influence won’t be enough to make headway in this change. (Although, do check out the Phoenix Project and the great Damien Edwards video “You Can’t Change Culture, but You Can Change Behavior and Behavior Becomes Culture” in my links below.) Based on personal experience, I believe DevOps does not work as a grass-roots or bottom up. You will need a CxO level advocate or an architect as a champion to move ahead.

Start out with a realistic view of what’s possible/achievable given the organizational makeup. Flat organizations do have a better track record of success. And keep in mind the important elements of culture your organization will have to demonstrate:

  • Collaboration
  • No-Blame Postmortems
  • High-trust culture
  • Experimentation and risk
  • Strong focus on continuous improvement
  • Good information flow and bridging between teams

I talked yesterday evening with someone that had an architect that realized their cloud-based infrastructure was costing them thousands of dollars monthly. He told the development team that they were going to be taking DevOps seriously – and that their environments would be completely disposable. Every night they would tear down their machines to a bare minimum – and every morning they’d rebuild them again. It worked brilliantly. That’s the kind of game-changer you need on your side.

A study by Westrum in 2004 divided organizations into three general categories, based on their orientation and base characteristics. Is your company Pathological, Bureaucratic, or Generative?

(courtesy Puppet Labs)

If your organization is Pathological, the best advice I can give is to focus on what you can do, and keep your own house in order. Have CI and RM in place – but know in advance, your odds of instituting meaningful DevOps are fairly low. This is because these types of organizations do not lend themselves well to the cross-team collaboration that will be vital for your success. Bureaucratic organizations are relatively friendlier, but there still will be a significant amount of inertia for you to overcome. Forming a DevOps Center of Excellence here or bringing in outside consultants to help sway decisionmakers may be a difference-maker here. If you’re in a Generative organization, congratulations – your pilot efforts will likely be the first step on a successful road to DevOps that will make your work-life as a developer much, much happier. Automating tedious tasks and not getting drowned in firefighting or unplanned work means a happier YOU.

History reveals some seemingly counterintuitive facts about DevOps adoption rates – Curiously enough, larger organizations and Windows-based vs open-source orgs have a higher rate of success in adopting DevOps. Looser open-source or smaller teams may not have the consistent level of discipline it takes to make DevOps stick. (Maybe too much freedom is a bad thing?) And, some of the best success stories come from the worst starting point. Pain is a powerful catalyst for change. If things are going well or even just OK, there’ll likely be little impetus for something as far-reaching as DevOps.

In discussing with management the key points of DevOps, stress the following benefits:

  • Our ability to ship features quickly and speed of deployment will rise dramatically.
  • We’ll be able to react quicker to your feedback as stakeholders and incorporate them into our feature prioritization.
  • We’ll be able to recover from failed deployments quickly and have smooth rollbacks.
  • Happy cows make better cheese. DevOps practices increase employee satisfaction, which leads to better business outcomes. A strong IT org means a profitable company. DevOps practices lead to a strong IT org. DevOps will lead to a healthier team.

If that doesn’t work, mention metrics. They may not care specifically about RM – but they will care if it drops your defect rate by 50% and increase their profits by 100%. And you can always mention the scare story of Knight Capital, which – by not instituting release management and DevOps earlier, lost $450 million dollars in the course of 90 minutes in August 2012. Studies show that high performing IT orgs are 2x as likely to exceed profitability, market share, and productivity goals. There’s a strong correlation between robust IT organizations and continuous delivery practices and productivity.

There’s other ways to change culture. I’ve heard of some companies seating engineers/ops next to each other, hiring consultant/mediators to streamline implementation, and forcing devs to be responsible with pager duty.

A healthy team = trust. Good feedback loop, crossfunctional collaboration, shared responsibilities, learning from failure. You’ll have a happier, easier, less stressful life as a developer. What’s not to love?

 

From Zero to DevOps in 180 Days

Here’s a sample recipe you could put together in trying to implement DevOps in your company. We’ll be realistic and pragmatic here, and assume that the first step must be taken by us, the developers – and after a trial period we’ll have Operations teams chiming in for a second phase:

First Phase: Getting Your House in Order (Month 1)

  • Devs take first step
  • Basic release management
    • Automatic provisioning of clients / config management
    • Continuous Integration
    • Beginnings of automated testing, version control
    • Elimination of feature branches
  • Peer reviews begin (NOT external change approval

 

Second Phase (Month 3)

  • No-blame postmortems
  • Published dashboarding of automated test coverage
  • Regression bugs identified by tests fixed immediately
  • Toolset experimentation begins
  • DevOps CoE publishes metrics and lessons learned / goals
  • Visibility is key

 

Phase 3: Ops-centric (Month 6)

  • Proactive monitoring, analytics, incident resolution
  • DevOps awareness / training seminars
  • Beginning of automating pain points
  • Next up – Build-Measure-Learn or Hypothesis-Driven Development

 

Wrapping Things Up

We haven’t talked about tooling yet. I’m going to walk through Chef and Puppet Labs integration with Visual Studio in a future blog post, and the same for deploying bits using the new Release Manager application integrated with VS. I have another post on Application Insights as well, which will help you expose to your business partners your test coverage and website performance. All of these things are important – but I believe the people and process side of things are MUCH harder and more fundamental to DevOps than any particular tool you end up selecting.

DevOps means replacing what WAS a vicious, nasty cycle of recriminations and backbiting with a virtuous cycle. Devs work closely with IT early on, stability improves. As stability improves, IT performance improves, and you start getting some meaningful feedback and metrics to prime your backlog. The first step is the necessary one of treating QA people and Operations as equal partners, early on in the process, and getting them involved in the design. Chef environment deployments must be built out along with your code bits, early on – give them the time they need to scale out so they can do their job.

So here’s some closing thoughts on how to make your journey to DevOps as smooth as possible:

Don’t form a single DevOps team. That doesn’t mean don’t begin with a cross-functional pilot team as a proof of concept – that’s actually a good idea – but forming a single DevOps team misses the point. From Jez Humble’s blog: “The DevOps movement addresses the dysfunction that results from organizations composed of functional siles. Thus, creating another functional silo that sites between dev and ops is clearly a poor way to try and solve those problems. (i.e. a cross functional team)”

Go slow to go fast. Recognize IT as an investment, and secure management support as a precursor. Start small and grow – gather data, and iterate. Gauge user response, collect metrics on things like MTTR/MTTD, and rinse and repeat.

Encourage experimentation. Propose a change and promise to reevaluate in six months or some other time limit. Make postmortems blameless. Practice root cause analysis (think of the “Five why’s”), and keep a detailed log of events without fear of punishment. Don’t level personal criticism at anyone, and don’t take feedback personally. Managers, it’s up to you to create a culture where it’s safe to fail.

Choose your tools wisely. There’s a variety of RM and infrastructure tooling out there, and each have pros and cons. Whatever you do, make sure the entire group has input on the tool of choice so you have their buy-in. You’ll want an integrated toolset based on loosely coupled platforms – one that can automate all those formerly painful manual steps, and where you can provide visibility and transparency through application monitoring.

Take that Ops handshake seriously. We need to think as devs about how Operations will monitor and support the software we produce. And pay attention to the little things – keep your promises, foster open communication. I have seen in multiple war rooms good and bad examples of how to act when things go wrong. If you behave predictably and calmly when the wheels come off, your Ops team will begin to take your words of partnership seriously.

Don’t go it alone. Incubate your DevOps movement with a Center of Excellence. Fold in your business analyst and business owner, and track metrics. Hold seminars or devops awareness brownbags. Some of the resources below in the links are very helpful – again, I’m referring to the Phoenix Project book in particular.

If you’re having trouble being taken seriously, think about bringing in some help. I worked at one organization for several years as a development lead and became very frustrated at our slow rate of adoption of ALM and DevOps. Once we brought in some Microsoft resources, they were able to hold workshops and chart out a clear path for us that was reasonable in scope and fit our business and cultural background. Within 18 months, you wouldn’t have recognized the changes in the development teams – we had an integrated set of tools and processes that the developers loved, and got our releases out the door much more quickly to the delight of our customers. Having that independent third voice in the room really made all the difference for us in getting our dev maturity level off the ground. Good luck!

 

Link Goodness – For Devs (specific implementation details)

  1. Excellent courses available here – http://www.microsoftvirtualacademy.com/training-courses/devops-an-it-pro-guide
  2. And here: http://www.microsoftvirtualacademy.com/training-courses/assessing-and-improving-your-devops-capabilities
  3. And get this book – it’s becoming a standard, along with the Phoenix Project from Gene Kim. https://www.safaribooksonline.com/library/view/continuous-delivery-reliable/9780321670250/
  4. This demo is an excellent walkthru- http://blogs.msdn.com/b/visualstudioalm/archive/2014/11/11/using-release-management-vso-service-to-manage-releases.aspx
  5. Channel9 videos on DevOps – http://channel9.msdn.com/Tags/edge-devops
  6. A nifty walkthrough of Puppet integration with Visual Studio Online – http://channel9.msdn.com/Shows/Edge/Edge-Show-110-Puppet-on-Azure
  7. Brian Keller does a 10-minute walkthrough of RM deployments (excellent for getting started with infrastructure as code) – http://channel9.msdn.com/Events/Visual-Studio/Connect-event-2014/214
  8. Great list of resources – http://www.itproguy.com/top-2014-microsoft-devops-learning-resources/
  9. Books that everyone appeared to quote and that seem very influential are the Phoenix Project with Gene Kim et al and Jez Humble’s book on Continuous Delivery. Of the two, if you just want a good yarn, start with the Phoenix Project. For a more technical approach, Jez’s book is excellent.
  10. http://www.microsoftvirtualacademy.com/training-courses/azure-resource-manager-devops-jump-start
  11. Great blog site for DevOps – http://www.donovanbrown.com/

For Business People / Architects (more general or on culture)

  1. A GREAT video on culture changing – “You Can’t Change Culture, But You Can Change Behavior, and Behavior Becomes Culture” http://vimeo.com/51120539 – Damon Edwards
  2. http://www.computerworld.com/article/2851974/microsoft-study-finds-everybody-wants-devops-but-culture-is-a-challenge.html
  3. http://www.citeworld.com/article/2115209/development/what-is-devops.html
  4. “There’s often a gap between devs and operators – devs motivated by innovation, pushing the envelope, and system admins tasked with security/stability. I think of DevOps as the bridge of that gap… since we’ve invested more in Ops, been a lot easier for us to get our services out there and actually delivered…. Expensive and timeconsuming to rollout a new feature, even if meticulously scripted often didn’t get it right – discrepancies between dev/prod systems.” – Bess Sadler, Stanford https://www.youtube.com/watch?v=L9V8oEaZ71I
  5. The PuppetLabs blog on Devops has a wealth of culture change information: http://puppetlabs.com/blog-categories/devops
  6. Puppet Labs 2014 whitepaper detailing org benefits of DevOps – this is very thorough: http://puppetlabs.com/sites/default/files/2014-state-of-devops-report.pdf
  7. MS site on DevOps – http://blogs.technet.com/b/devops/
  8. The rise of Shadow-IT – “A very tangible, negative side effect of this situation is Shadow IT, where developers create their own ways to deploy and run their solutions, in order to maintain the required speed of change and flexibility, and to respond to ever growing demands. One example of this is cloud technologies with easy-deploy options and pay-as-you-go offers foster Shadow-IT, which frequently leads to the drifting apart of development and operations teams, leading to a Shadow-IT scenario.”
  9. VM’s and hands-on labs: http://aka.ms/ALMVMs
  10. Great article on DevOps including a checklist and sumup: http://www.devopsonwindows.com/it-takes-dev-and-ops-to-make-devops/. I love their article on removing config files and the checklist rocks.
  11. A nice interview with Yelp on how they were able to institute change, focusing on listening, being humble, and understanding the patterns your org has in place before advocating widespread, permanent changes – http://puppetlabs.com/blog/change-agents-it-operations-what-it-takes
  12. Gene Kim – how do we Better Sell DevOps? http://vimeo.com/65548399
  13. I also like the no horse crap video https://www.youtube.com/watch?v=g-BF0z7eFoU
  14. DevOps resources and links – http://www.itproguy.com/top-2014-microsoft-devops-learning-resources/

Lifehacks and my State of the Union address :-)

We live in constant tension between the urgent and the important. The problem is that the important task rarely must be done today or even this week.  … But the urgent tasks call for instant action—endless demands pressure every hour and day. … The momentary appeal of these tasks seems irresistible and important, and they devour our energy. But in the light of time’s perspective their deceptive prominence fades; with a sense of loss we recall the important task pushed aside.  We realize we’ve become slaves to the tyranny of the urgent. -Charles Hummel

So as some of you know I’ve been looking more into productivity tooling and lifehacks since shortly after I started this new job back in July 2014. Microsoft as a whole is such a vast company – and there’s such a torrent of information – that quite a few very bright people struggle to keep up. I also would like NOT to be up till ten at night, getting no exercise, and not really making a lot of progress on real work. You know the saying “Some things are urgent, and some things are important – but not everything that’s urgent is important, and not everything that’s important is urgent.” I saw a lot of that in previous work – I would dump my all into a career, or a company – and my family and personal health would suffer.

So I tried the following things:

  • Don’t check email in the morning. I set “email block” meetings in Outlook from 12-1, and 4-5 daily. In the other times, turn off Outlook.
  • Eat that frog. Plan 2-3 most important (not urgent) actions on calendar and get it done.
  • Reflection. End of day – what did I do today? What will I focus on tomorrow? What could be improved?
  • Time management. Pomodoro (50 minute working cycle / 20 minute break. P.s. sitting all day is TERRIBLE for your health, even if you work out)
  • Personal fitness. Paleo diet and Crossfit mostly. I flirted with vegetarianism briefly, and even went off coffee for a month (otherwise known as the WORST MONTH OF MY LIFE)

Here’s what worked:

  • Crossfit is terrific, and so is Paleo. Changing up my diet and focusing on working out and strength training – hard as it was – was a game changer for me. I’m stronger than I’ve ever been and am losing weight, at long last. I feel like a hero around my girls, which is worth quite a bit.
  • Doing a technology detox (see the pix below) was actually a good exercise. We went without TV for a month, and I uninstalled a lot of social media apps off my phone. Guess what? Life gets better after FaceBook.
  • Not checking email in the morning made a HUGE difference in making me less reactive. If you try only one thing from this post – DO THIS.

Here’s what didn’t work:

  • I didn’t really focus on keeping Important things foremost. Too many times the more important things slipped behind the urgent issues of the day.
  • Pomodoro was NOT GREAT for me. I am thinking of retrying it in the future, but since much of my calendar is meeting driven not heads-down programming – it just didn’t apply.

Here’s my goals for the future:

  • I’m convinced that buying out the time for myself and my family first – esp with health-related things like exercise and diet – is vital for me to be really productive. So I’m going to push ahead with this. Seven days successfully on an improved diet and the odds are you’ll stick with it – yet most people THINK they lack the self-control to make this change, and so they drop out on day 4 or 5. I have all kinds of events coming up and free lunches – so saying no to this is hard – but going alcohol-free and sticking to Paleo is really good for me in all areas of life.
  • I will add to my daily diary routine more of a reflection on life and the big picture.

 

One last picture again. This really sums it up.