It's the Ranger4 #DevOpsFriday5 series - today's contributor is Mustafa Kapadia. He's DevOpstastic!
1) What's your preferred definition of DevOps?
This is a great question. There are so many different definitions of DevOps floating around, its enough to make your head spin. If you ask 10 people, you are probably going to get 12 different answers.
For me DevOps is about creating more value. You can make the argument, that in a Software Delivery Lifecycle (SDLC), value is created in two places. First when the idea is turned in code (development) and second, when that idea is delivered to the customer and feedback is received. The faster one can move code from the developer to the customer and receive feedback, the more value is realised by both. DevOps is about focusing on the processes that add value, organising around those actions, and doing the best to minimize the risks.
In other words, DevOps is about streamlining our SDLC so that we can bring an idea to market faster and be more responsive to our customers.
2) When people 'do' DevOps, what's the most common mistake you see them make?
I see two mistakes over and over again. First, the focus is only on automating certain activities and second, no real thought is put into understanding the overall SDLC flow. Separately they create subpar results but put together they have a devastating impact on the team’s initiative.
The problem with “automating current activity only” approach is that its focus is too narrow. Lean law follows the 80/20 rule. 20% of cycle time is considered to be productive “hands on keyboard” work and 80% is attributed to waiting, rework, waste etc. If all you do is automating the “hands on keyboard”, then all you have done is impact the 20%. The 80% remains untouched around. No wonder teams end up scratching their heads as to why things are not moving faster.
Which brings me to my second point. DevOps is about streamlining the flow of your entire SDLC. Starting an initiative without understanding / measuring the overall flow and the impact of your activity to that flow is a recipe for disaster. If you don’t measure your current state (both the 80% and 20%), how can you tell if you have made progress and be able to communicate your benefits.
I cannot tell you how many times I have walked into the client site to find the team demoralised, frustrated, and in some cases ready to give up simply because of these two actions alone.
3) How do you recommend an organisation new to DevOps start?
Related to the above answer, I believe the best way to start the DevOps journey is to:
- Understand / measure overall flow and identify bottlenecks
- Pick 1 / 2 practice areas to attack. There are 12 key practice areas, I recommend starting with the low hanging fruit
- Pick an application to pilot
- And once you have a deeper understanding optimize and expand
A few words of advice - don’t just stick to the 20%. I know that feels safe, but if you want to make real change focus on the processes in between and around the activities as well (i.e the 80%). That is where the real inefficiencies are hiding.
4) What's your prediction for what DevOps will look like in 2020?
There are a lot of similarities between DevOps and lean manufacturing implemented in the automotive space. Early adopters of lean manufacturing (Toyota, Hyundai, Honda) have enjoyed a price / loyalty / quality premium for the last 2+ decades. The late adopters (GM, Chrysler, Ford) are only now catching up and while you can argue that they are just as good as imports (and in some cases even better) they suffer from poor market perception. Which translates into a very real impact to the bottom line - when was the last time a domestic car commanded a rice premium over an import. If DevOps follows the same path, I think by 2020 we will have some early adopters that will enjoy the market premium for some time to come and the rest will be left playing catch up.
5) Where do you like to go to get a DevOps hit?
Too many to mention but some of my favorites are ….DevOpsFriday5 (big fan of this format), DevOps.com, HighOps.com, IBM’s DevOps Community, and DevOpsguys.com. Also, one of the benefits of being part of IBM is that you are surrounded by brilliant DevOps architects. There are several but it would be a shame if I did not mention two in particular, Andrea Martinez and Ron Adinolfi. Both are excellent and my key go to resources for DevOps.
Mustafa Kapadia is the Service Line Leader for IBM's DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.
His expertise is in DevOps, cloud, lean, application development, outsourcing, offshoring etc. Industry experience in Technology, Financial Services, and Telecommunication etc. He has published several articles on DevOps, including “How To Get Started With Enterprise DevOps” and “Three Popular Misconceptions About DevOps”.
Prior to joining IBM, Mustafa was a management consultant with Deloitte's Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and advisor to start ups.
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.