What the "F" is DevOps?

Recently Attended "DevOps Days India" here in Bangalore. Those two days with people who either are in DevOps role OR want to adopt it, forced me to rethink: "What the F is DevOps?"

A little background first
This two day conference had lot of stuff, but to me it missed the basic concept of DevOps days. And was the introduction to DevOps.
To fill that gap I proposed the same topic for "Open House/Session" and to my surprise lot of people voted to discuss that :-)

During the Discussion
Lot of people gave their opinion about this, some of them were:

• DevOps means Developer + Operations. It doesn't contain QA else it should be QAOps.
• It is a Developer who knows Ops (specifically system administration).
• It is an Ops guy who knows about Development.
• The guy who builds and deploys.
• The guy who sets up tools for daily use.

My Idea about DevOps
DevOps originated from two words: Development (not Developer) and Operations (not sys admin or similar)
Here Development includes any activity done to build the product/service (including QA) and Operations consists of all the activities included to keep it up & making money out of it.

So in my opinion DevOps is all about solving issues, resolving blame games and bridging gaps between teams.

So In short it is not a guy or a team and definitely not a tool.
DevOps is a philosophy that anyone in the team can implement. It is about solving any issue using: Processes, Tools or People. It is also about solving the issue for good (not just for now).

Few example would be:
Issue: Bugs are caught later in the SDLC
Solution: Introduce CI and SCM tools to get results faster. Introduce Agile process make people react faster incase of issue.
Type: Solved issue with Tools and process.

Issue: Teams have no idea about the other teams work.
Solution: Get the team working on Collaborative development. Get them to work together (may be in a single room) on a periodic basis. Conduct brown bag sessions etc.
Type: Solved issue with people and bridging gaps between them.

Issue: Who owns the build failure?
Solution: CI tool send the email based on the failure. Example: If the build fails while compiling or test cases fail then the culprit's email goes to developer, but incase the test case have issue in running then QA gets the culprit's email.
Type: Solving blame game.

Then who is a DevOps guy?
I don't believe in such a role, but still it is a guy who has experience with solving issues. Who can look at a problem like a consultant and give a solution without being getting stuck in the problem itself.
So in generalised term:
DevOps guy is the person responsible for implementing the DevOps Philosophy across the Organisation.

Good to be Agile

It's been a long time that I wrote any blog, so now here I am again.
This time I think the best topic to share is working with Agile methodologies.

It's been more than four year now that I have been working with the same. Some initial questions may occur in the mind of the reader of this blog.

Questions like:
- What is actually AGILE?
- How can it make my work better?
- What are it's pros and cons?
- etc. etc.

By definition agile means quickly producing something useful and improving it over a period of time to the best of it's type.
But quick doesn't means to forget the real iterations required for the process.

I will put an example here:
Suppose you are developing a software, under waterfall model we start coding finish the project over a period of time and pass it to the customers.
But in agile we start coding get some thing usable (something like a prototype) pass it to the customers, then start improving it (taking help from customer's feedback). This ends up in a better end product as it includes customers feedback also. And a software which has passed phases like creating prototype, testing, retrofitting etc. (real time iterations), is of greater value to the customer.

There are various Agile methods, our need defines as which one will suit us the best. Example:
KANBAN:  A method for developing products and processes with an emphasis on just-in-time delivery (using KAN="Visual" BAN="Board" technique) while not overloading the developers. With proper use of Kanban, projects are able to eliminate bottlenecks from any part of development cycle.

SCRUM: It is an iterative and incremental development process, where effort is tracked by burndown charts (each sprint) and Velocity tracking (over many sprints). These metrics help in better, predictable sprint planning and hence delivering happy faces.