Don’t Do Agile and DevOps by the Book


In software development, we talk a lot about the importance of Agile and DevOps. Agile aims for rapid releases, positively encourages involvement from customers and other stakeholders and splits work into smaller iterations, releasing as soon as possible. DevOps extends it by introducing cross-functional team collaboration and automation, enabling teams to always have a stable build ready to deploy.

That’s the short version and there’s a huge range of books and frameworks out there to read so that anyone, anywhere–apparently–can just start doing it. The danger is that if you follow them too closely, processes can actually become too rigid, so you end up losing the agility you’re striving for. I always get suspicious when theories in books are read and regurgitated completely without thinking about the actual situation on the ground. I’d much rather have a conversation, write up our notes, try it out and see how it can be improved.

Clearly, I’m not saying that you shouldn’t have boundaries and rules. I worked for a company that moved from no processes at all to adopting Agile methodologies. It needed to put in place a framework to guide people in the right direction, particularly initially.

As companies mature though, they need to look at what works best for their particular situation–otherwise the danger is that common practice masks commonsense. You end up following processes, such as two-weekly reviews, that don’t necessarily match your needs–why wait two weeks for a review, for example, if something obviously needs fixing today? Where did Agile go?

What Does Agile Mean for You?

The best place to start is to define Agile for your organization. On the positive side, definitions of Agile are very broad–but the flip side of that is people get confused about what terms actually mean and whether they should be using them.

For me, Agile is about being able to change the way you work, reflect on things and continuously improve. The biggest goal is to bring in very short feedback loops and be in a position where you can do something when you get that feedback. After all, there’s no point having a quick feedback loop if you can’t adapt or react equally quickly. 

I’ve deliberately kept this definition high level–it’s important not to mandate exactly how you deliver Agile. For example, we use a variation of Kanban in our team, based on the original methods adopted by Toyota, having switched from a flavor of Scrum. I’ve had people come up to me and say we’re not really doing Kanban properly, as we’re not following every step of it rigorously. That’s not an issue–we’re using it in a way that matches our needs and goals.

The Components of an Agile Philosophy

One of the reasons that people follow Agile books and processes is that it’s easier than looking at your culture and mindset. In software, I believe we’re more interested in the output of our minds, rather than the output of our hands. We have bodies, but they’re primarily there to move our minds to meetings. What becomes difficult is if we try and measure productivity by looking at the wrong metrics–essentially focusing on the output of our hands instead of our minds (how many lines of code have you written, for example).

You need to move away from this and create a culture with four pillars:

  • Everyone is committed to constant improvement: Even the best bit of code or greatest process can be improved, so teams need to be open to always try to get better at what they do and how they work (focusing on where improvement will have an impact). It isn’t a negative or an admission that you’re not up to the job. In fact, it’s the exact opposite–wanting to learn and improve is fundamental to Agile, and generally being a good developer. 
  • Everyone is free to share their ideas: I talked about the need for fast feedback loops, and that extends to everyone being able to give their opinions, without fear or worries about ridicule. There really is no such thing as a bad idea, as it can spur further thoughts that get you to a solution. For sharing to actually work, you need psychological safety in your team–people have to be confident that whatever they say, it won’t be held against them come review time. Forget the “I know best because I’ve been doing it for longer” approach as well. I’ve often seen young inexperienced developers come up with great ideas–because they’re young and inexperienced.
  • Everyone is encouraged to question everything: Building on the first point, people have to be prepared to constantly review the way they, and the wider organization, works. Why do we do it this way? Is there a better solution? This shouldn’t be a recipe for constantly changing working practices and not getting anything done though. Go back to your original objectives of what you’re trying to achieve and then question whether current methods are the best way of getting you there.
  • Teams don’t have to follow rigid methods: No one should be forced to work a certain way (that’s the antithesis of Agile). Instead, teams should be encouraged to find the way that works for them. There’s a whole range of Agile methods out there, and the combination you adopt should be focused on your particular needs. That’s where my suspicion of Agile books comes from–for me the perfect read would be one that just fills your brain with thousands of ideas.

Agile is at the heart of efficient, high-quality software development–just don’t risk losing its agility by following processes too slavishly and making everything you do too rigid and inflexible.

1 thought on “Don’t Do Agile and DevOps by the Book

  1. Tôi là kẻ-phản-bội-Agile, tôi nghĩ có thể nhiều người đang thực hành “tư duy Agile” và “áp dụng Agile” sẽ nghĩ về tôi như vậy.

    Tôi cũng không biết điều đó là đúng hay là sai. Nhưng nhiều khi bản thân tôi tự nghĩ về mình như vậy.

    Tại sao? Vì tôi thường xuyên nghi ngờ cái mà mọi người gọi là Agile. Tôi thường xuyên phải tự vấn hỏi mình thế nào là tư duy Agile (Agile mindset), mặc dù tôi đã làm, thực hành, áp dụng những thứ mọi người cho là Agile nhiều năm nay.

    Lịch sử google search của tôi tràn ngập những câu hỏi như vậy.

    Và đến bây giờ, tôi vẫn không biết thực sự Agile có thể phát biểu thành câu văn định nghĩa/khái niệm như thế nào cho chuẩn. Và khi ai đó tự nhận mình đang áp dụng Agile tôi sẽ nhìn bằng một con mắt đầy ngờ vực.

    Tôi chợt nhận ra, đối với tôi Agile là gì không quan trọng. Tôi chỉ cần biết tôi hướng đến một mô hình làm việc hiệu quả. Tôi muốn sự minh bạch thông tin, sự tin tưởng lẫn nhau cùng với thiện chí hợp tác khi làm việc cùng nhau.

    Tôi muốn công việc có kết quả thay vì quá chú trọng vào quy trình và tài liệu.
    Tôi muốn phát triển các cá nhân và sự tương tác giữa họ thay vì quan tâm đến quy tắc và công cụ.
    Tôi muốn đối đầu với công việc và chấp nhận sửa sai thay vì ngồi vẽ plan trên giấy.
    Tôi muốn làm ra sản phẩm tốt và dùng được chứ không phải cò kè từng chức năng với các bên liên quan.

    À, thì ra cái tôi muốn hình như cũng chẳng khác gì Agile manifesto mấy. Như vậy tất cả những thứ bóng bẩy bên ngoài để thể hiện là “tôi đang làm theo Agile đấy” chẳng có gì là quan trọng. Kẻ-phản-bội Agile cũng được, anti-agile cũng chả sao. Tôi vẫn sẽ làm theo cách của mình. Bất chấp nó có “Agile” hay không. Bất chấp nguy cơ bị cho rằng thiếu chuyên nghiệp khi áp dụng Agile nửa vời.

    Agile, go to hell. I’m just who I am.

Leave a Reply

Your email address will not be published. Required fields are marked *