Comments (7)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 MarcioAB commented Permalink

I was expecting the more traditional answer: depend. Allow me to justify with a fictitious interview: <div>&nbsp;</div> a) What do you make ? <br /> b) We make Speakers. <div>&nbsp;</div> a) Nice ... what kind of Speakers ? Those more traditional or the more "smarters" ? <br /> b) Yes, we still have some traditional, but we are more in this Smart Speakers business. <div>&nbsp;</div> a) Great. So, that means, you know need to deal with software, right ? <br /> b) Yeap. We had to acquire a small company to help us with that. <div>&nbsp;</div> a) Very Interesting. And how it changed your manufacture ? <br /> b) Well, it just made things up-side-down. <div>&nbsp;</div> a) Can you explain a little bit about that ? <br /> b) Yeap. We now deal with our customers at a weekly basis. We provide weekly upgrades for our smarter speaker. <div>&nbsp;</div> a) OMG! And how you do that ? <br /> b) Well. We figure out we had to became AGILE. And we did it. <div>&nbsp;</div> a) How ? <br /> b) First, it was just the development part that became agile, but them we discovered the manufacture need to follow the development. <div>&nbsp;</div> a) And how it happened ? <br /> b) Well. We figured out we had to upgrade our strategy, our manufacturing with something known as DevOps, so could finally deliver weekly upgrades for our smarter speakers. <div>&nbsp;</div> ... and the rest you already know.

2 wiedrich commented Permalink

Marcio, the ideas outlined in your example are perfect. As your probably aware a transformation to use DevOps and Agile concepts require changes in 3 things: People, Processes, and Tools. In most cases Tools can be free (open source) or purchased, but the People and Process changes require a resource investment. The larger the transformation effort the more resources and time investment required. So this means that instead of trying to tackle the strategy upgrade, manufacturing, and software delivery in your example, picking a single focus area requires a smaller investment but still yields benefits. You then identify the next area for transformation, execute, and repeat again.

3 MarcioAB commented Permalink

Hi Robb. Thanks to share. Thinking about your point or approach: focus initially in a single area ( Dev ) versus focus initially in both areas ( DevOps ) at the same time. That is an interesting discussion. For example: What if Dev became agile and Ops not ? I see issues. And these issues could compromises the entire strategy. Because in the end, the business ( the owner of the business ) wants a single piece of delivery. They need to deliver a product. I clearly understand that address both areas at the same time is ... complex (to say minimum), but I think it is necessary. It is not a tech decision. It is a business decision. And to deliver such kind of smart product, you must have DevOps working from the beginning. Does it make sense ?

4 wiedrich commented Permalink

I agree that the decision to adopt DevOps and Agile principles is a business decision, which will affect both Dev (development) and Ops (operations). Customers have continually changing requirements that put pressure on IT operations to deploy new or updated applications and services at the speed at which they get developed and then support them, while minimizing risk. IT operations and development teams need to be joined at the hip through integrated processes to make this happen. As a matter of fact, the DevOps movement is driving better alignment between these two teams as they seek to increase their change and release cadence. <div>&nbsp;</div> How does this relate to your point? Yes, if development finds a quicker way to turnaround a test cycle through DevOps solutions and Agile principles, then yes, operations will need to be involved along the journey in order to consume and deliver this function to customers. This means that you are transforming a single Dev to Ops process however your not changing the entire DevOps lifecycle. When we look at the full DevOps lifecycle as it relates to continual delivery it involves more than just testing. You have requirements, planning, prioritization, measuring, deploying, provisioning, and feedback.

5 MarcioAB commented Permalink

Maybe now I'm better understanding your point. Allow to double-check this using 2 nicknames to provide high contrast: Core_DevOps and Full_DevOps (or any other proposed nicknames). Core_DevOps represents the strong alignment of the core of these 2 very distinct organizations ( Dev and Ops ) around agile deliveries. Full_DevOps represents the entire end-to-end lifecycle as you pointed out in the end of your comment. <br /> Now, I fully agree with that resounding NO for Full_DevOps. <br /> But I still think, in the context of smart products delivery, that Core_DevOps is something that should be considered at first. My fictitious example about the smart speaker tried to emphasize this. They started isolated ( Dev only ), but then realized that if Ops does not became part of the equation, the business is not possible. So Core_DevOps should be ... a must ... in such context.

6 MarcioAB commented Permalink

Maybe this rise an important distinction between Core and Full. Like in ALM, this leads to Full_ALM verus Core_ALM. Rational nicknamed this Core_ALM as cLM, ( I know the "c" is for collaborative, but I never fully agreed with that, because if we added the "c" as collaborative we should have added also the "i" for integrated ). For me cLM was always Core_ALM. <br /> Now Gartner minimizes to talk about ALM and brings up another interesting nickname: ADLM ( Application Development Lifecycle Mgnt ). That means, people need to sub-divide large vendors or corporates strategies ( like PLM, ALM or DevOps ) into small pieces. <br /> For ADLM I do not see the need to nickname it as Core or Full. ADLM is more or less our cLM ( or Core_ALM or ADLM ). <br /> Core_DevOps is a small step towards into Full_ALM. And Full_DevOps is a giant step towards Full_ALM. <br /> The same is going to happen when these 2 giants ( ALM and PLM ) became seriously integrated as a single corporate strategy. <br /> And I think Core_DevOps is a good movement toward this direction ( ALM + PLM = Smarter Products ).

7 wiedrich commented Permalink

I think your differentiation of Core, Full, CLM, and ADLM make sense. In my mind, we try to use some of this terminology to cover all the bases, when in actuality all we are attempting to accomplish is Continuous Delivery of products/services to our customers. I think it's worth while to read Paul Bahrs blogs on this site and refer to his DevOps Maturity Model, which illustrates this discussion. Great discussion!