Whether you choose Scrum, Kanban, Lean or any other framework, if you only do that, you're not being agile.

No matter how many Post-its or other artifacts you produce, if you're not producing working software, you're not agile.

Agile, like family, cannot be scaled. But we can allow for it at scale.

Regardless whether someone belongs to the PO or PM school, they seem to have exactly the same complaints about the other.

If your team can't agree on a course of action, conduction a short-term experiment instead.

"It's not operation's job to keep the site stable and fast. Operation's job is to enable the business."

In the same way that tools don't make art, tools don't make DevOps.

In the first of what may become a semi-regular feature of my daily list, I’m going to make a book recommendation. Regular readers likely already have a sense that I like find inspiration in unusual places, so I’m not recommending an IT-related book. Antifragile: Things That Gain from Disorder by Nassim Nicholas Taleb provides an interesting look at systems that are antifragile. Taleb contrasts “antifragile” against the more intuitive concept of robustness or resiliance.

A couple of years ago I was working with a team responsible for an eCommerce platform undergoing a platform migration. When I joined the project, it was already behind schedule and over budget. For several months, the migration project was continually “80% done”. The new platform was getting closer and closer to “ready,” meanwhile the legacy platform was becoming harder and harder to maintain. What’s worse, every functionality change on the legacy platform had to be re-implemented on the new platform, too, so that the eventual switch wouldn’t represent a regression.

I frequently encounter people wondering how Scrum and DevOps relate to each other. Or as it was recently put to me: Is DevOps better than Scrum? I like to answer this question with the aid of this popular DevOps worfklow diagram: This shows seven distinct activities in the DevOps lifecycle, and how they relate to two broad roals: Development, and Operations. Plan Create Verify Package Release Configuration Monitor Scrum, in contrast, defines the relationship between the business (personified by the Product Owner), and the development team, and provides 5 key activites:

I’m frequently asked about the ideal team structure for DevOps. A common sentiment suggests that the only “proper” way to do DevOps is by having developers and operations people on the same team. Otherwise, the thinking goes, you have the old dev and ops separation that DevOps is specifically intended to eliminate. While this comes from a good place, it’s not actually the only valid way to do DevOps. Let me offer two models for successful DevOps.