You’ve heard about Devops and you like the idea. But how can you grow a Devops culture in your organization? In my series about Devops Protocols I talk about the fundamental building blocks for growing a Devops culture.
No Manual Changes refers to the behavioural trait of not messing with any productive systems. Let’s discuss why messing with production systems is bad and what to do about it.
Click to continue…

In most enterprises, employees are referred to as resources. Heck, it’s even worse. There’s a whole department dealing with human resources. This, my friend, is bad. It’s bad because it kills the most basic ingredient for agile success: Respect. Respect for your employees. Let’s have a look and see how respect builds the foundation for your success with agile.
Click to continue…

As a desktop application business, you decide to take a chance and jump onto the “Web” bandwagon. Sure, this whole Internet thing has been hyped for a decade, but maybe there’s something to it after all? Your first idea is to tackle that old workhorse called E-Mail. Pictures are only getting bigger and you just can’t seem to push those snapshots around to your friends and family anymore.

“What if you could upload them to the “Cloud” and mail just the link for viewing?”

“Great idea, and there are some really excellent web services that offer this already. Maybe we could just use one of them?”

“Nah, we could do it way better and I have a few more ideas. We know what our customers really need.”
Click to continue…

We all know that protocols are an essential building block of our craft. What would our jobs look like without TCP/IP or HTTP? While there is room for improvement in all of them, they’re definitely helpful in defining how our systems work together. But systems programming are not the only area where protocols play an important role. Wikipedia talks about protocols in diplomacy, for example: “A protocol is a rule which guides how an activity should be performed”[1]. Ah, now we’re getting somewhere. So why not apply the ‘protocol’ idea to Devops? Let’s try and see how the idea of protocols can help us improve the adoption of a Devops culture.
Click to continue…

You know by now that Code Inventory is something of an obsession with me. Like it or not, most of us, whether developers or sysadmins, work in a service industry. It’s fast and furious, and we don’t have time to build features that nobody wants. With sufficient test coverage, there’s no code that can’t be released within a day of pushing to the repository.

A couple of years ago, I showed you how to Visualize Small Batch Sizes with Git by plotting day-to-day the amount of changed source code lines that hadn’t yet been released to production. While this graph gave immediate feedback about the “drift” of development from operations (live), it’s not something easily digested by upper management. What do these guys really care about? It’s all about the releases silly!
Click to continue…

This is a guest post by Kevin Parker, VP and Evangelist, Serena Software

For those that have to deal with release management, release train is a well-understood term. It refers to a software development schedule where multiple products are released as a part of a single ‘train’ on a regular, pre-planned schedule.

But just as a train can be late thanks to leaves on the line, a fatality or engineering trouble, so release trains can be delayed by both internal and external problems. In order to solve this, it’s time to get off the train and look upward for inspiration.
Click to continue…

In the past decade we’ve seen thousands of companies introducing agile methodologies. A lot of teams started introducing scrum, re-structuring the way they work, and … getting stuck after a couple of months. Why do most agile introductions come to a screeching halt? Why do so many teams either fall back into old habits or decide that “This scrum thing doesn’t work for us!”? Let’s take a look at what makes agile fail.
Click to continue…

This is a story about merging two teams. One was using a physical Kanban board and the other was using an electronic one. Of course we were discussing the pros and cons of electronic versus physical boards. My role in the discussion was pretty funny: I used to be a very strong fan of physical Kanban boards but found myself arguing for the electronic version. Below, you’ll find some of the more convincing arguments from both sides.
Click to continue…

The Lean Startup teaches us to focus on learning about what really works for our customers. It advocates using the scientific method for running data driven experiments in very short cycles. But, continuously running end-to-end experiments need the total cooperation of the entire business. Truly cross-functional teams are required which is also one of the goals of Devops. Let’s take a look how the ideas of The Lean Startup and Devops enrich each other to successfully create product development flow.
Click to continue…

You hear a lot about various agile approaches. Things like Lean, Scrum, Kanban, and Devops seem to be important but it’s hard to sort them out. How do they relate to each other and where to start? Let me try to structure these ideas for you.
Click to continue…