Hi, today not about clouds, but about DevOps. This article is a transcript of part of the “DevOps” podcast. I would like to thank Mateusz Bogolubow from devmentor.pl for the invitation and nice conversation.
During the conversation, I had very interesting questions, which I tried to answer as best as I could. In the end, a very good material came out, telling what DevOps is, where it comes from. We talked about whether DevOps is a culture or a work methodology, about its strengths and weaknesses. We talked about how to get started with DevOps. What skills are worth having, what tools are worth knowing and of course what DevOps has to do with Agile.
Part of the conversation can be found below, and the entire podcast in Polish can be found on:
- YouTube – Wprowadzenie do DevOps | Pierwsze kroki w IT #55 [ IT podcast ] – YouTube
- Spotify – Wprowadzenie do DevOps – Pierwsze kroki w IT | Podcast on Spotify
- Google Podcast – Pierwsze kroki w IT – Wprowadzenie do DevOps (google.com)
- Apple Podcast – Pierwsze kroki w IT: Wprowadzenie do DevOps on Apple Podcasts
Does Agile have anything to do with DevOps?
Ok, so Agile and DevOps are different, but not mutually exclusive.
○ “Agile” – an agile approach to project management and software development, helps teams deliver value to customers faster. Instead of creating one large implementation, Agile teams deliver work in small but usable pieces.
○ Traditional Cascade approach to project management – Waterfall, forced a very long time of waiting for the finished product. The assumption was that when team 1 finished the work, then the next team could start working. Everything followed a predetermined schedule. One stage had to end before the next stage could begin. Unfortunately, frequently changing conditions and assumptions caused the extension of the implementation time and drastically increased the costs of some projects, leading to the closure of projects before they were completed.
○ The answer to these problems was an agile approach to project management. Agile methodology can be briefly described as an approach that aims to maintain productivity and deliver a product under conditions of constantly changing needs.
○ It’s not that waterfall doesn’t work anywhere. Each approach has its pros and cons. Waterfall works well where the requirements remain constant, where no changes are made, or only a small amount of them are introduced, because introducing changes is very expensive. Ok, so where can it work? For example, it could in the production of a car or some other production line. As I mentioned earlier, where the initial assumptions do not change.
○ The IT world is changing very quickly. The mindset in the Agile methodology, adapts to this, is to react quickly to changes and errors. “Agile” is focused on flexibility and adapting to the needs and expectations of the client, not the implementation of rigidly defined plans. So to put it very simply, quick response to changes. For me, this is such a logical approach to solving problems that has been described. That is, an attitude to work better, more effectively, an attitude to constant development and, at the same time, risk reduction by receiving feedback and making sure that we are going in the right direction. At least that’s how I understand this. If anyone would like to know more about Agile, the Agile Manifesto (Agile Software Development Manifesto) was created in 2001, which is a declaration of common principles for agile software development methods. I don’t want to go into that now, because we might not have a day to explain it. It is important that there is such a thing and if someone would like to explore the subject of agile, they should start with this. Here I can also recommend one of your podcasts in Polish, in which you focused more on scrum and agile approach: Czy Agile to Scrum? O różnicy, sposobie myślenia i wdrażaniu | PKwIT #44 [ IT podcast ]
○ When it comes to the approach to the customer, Agile focuses on frequent contact with the customer and giving them value. So the client sees the work, with each meeting, every 2-3 weeks sees progress and receives something valuable. The important thing is that he always has an impact on what is happening. At every stage, it has an impact on the product we deliver. Thanks to this, this cooperation is going well. The client willingly cooperates, talks about what he needs. In fact, it may turn out that the final product will be different from the one we talked about at the beginning, but the customer will be happy because he will get what he really needs.
○ Teams that work agile tend to complete smaller tasks that can be completed faster. Transparency of what someone is doing and at what stage they are at increases and the number of work in progress, such tasks started but not completed, decreases. We see exactly what’s blocking us and we can react quickly to it.
Summary about Agile and DevOps
○ Both “DevOps” and “Agile” enable faster delivery of the final product. Importantly, you don’t have to choose between DevOps and Agile – you can use both. You can work in the DevOps methodology and choose what else you need, e.g. scrum is useful for tracking planned work, such as updates, migrations, etc. Sometimes unforeseen situations occur, such as a security breach, and it cannot wait in the backlog for the next planning session, so the kanban methodology will work better. Teams sometimes use a hybrid of different methods to work. They just use what works.
○ A strong point of the Agile methodology is organizing work, as I mentioned earlier, for example using Scrum and Kanban tools. DevOps methodology, on the other hand, has a greater reach and allows software to be delivered faster and more reliably. It places great emphasis on automating processes and providing quick feedback.
Learn more about DevOps
If you are curious what happened next, you can watch the whole podcast in Polish on … . Get ready for a solid dose of knowledge because the podcast lasts almost an hour.
If you enjoyed the podcast, then I have good news, I will be participating in another podcast soon, this time about Docker. More information coming soon.