The secret recipe of successful Agile and DevOps

For years, I wanted to write about my take on Agile and DevOps. I never did because I feel there is no value in expressing an opinion if it’s not backed by facts. Today, I am finally in the position of sharing my opinion after having tried and tested successfully Agile and DevOps. I am going to write some controversial stuff and use some colorful language. Please sit tight and have some water by your side.

Common sense over process

If you need to learn one single thing about Agile, it is without doubt this quote from its Manifesto:

Use your common sense over processes and tools. If you think that to introduce Agile in your company all you need is adopt the Scrum framework and start using JIRA, abort now! You understood nothing about agile! Press the stop button and rewind! If you employed some certified Scrum or whatever expert, send him home! (I’m joking, don’t send anyone home but keep on reading)

The very first statement in the Agile Manifesto is telling you clearly that focusing exclusively on process and tools is not the solution!

Establishing a strict process based on some dogmas you read in a book, or even worst in a random blog on the internet, it is just a lazy way to not address the real issues that are afflicting your company. Yep, that’s the true story! You might have issues in your company and you are so lazy that, instead of addressing them, you think adopting some funky buzzwords and processes like fairy dust is gonna solve any of them! Ahahahahah!

If you have issues, such as slow delivery times and poor collaboration between teams and departments, you need to do some introspection first. This is the important part about individuals and interactions.

Here it comes the first and most important ingredient to successful Agile and DevOps. You need to have motivated and skilled individuals who share a common goal. And if you are sharp, you can notice this can be an alternative definition of both Agile and DevOps. DevOps is about culture, automation and team self-sufficiency. The self-sufficiency part is to make sure the team is focused on one product and set of goals. If you have multiple teams or departments with different goals and priorities, how do you expect your product to make it to production quickly? It’s impossible.

Create a team with the right set of skills and experience and empower it by making it exclusively responsible for a product. Apply pressure and set the bar high. Results will come home. Guaranteed.

You have also the option of keeping your departmental structure in the company if you don’t fancy the DevOps idea, or you simply don’t have enough resources to put it in motion. At the very least, set your priorities right across the entire company. If you want a product to make it to production asap, it has to be a shared priority across departments from day 0 (not 1).

Working software, collaboration and change

The real goal of any employed person is to bring home the bacon. It is the same for the company you work for. If you work in the software industry, the only way you bring home the bacon is if you deliver that ****** piece of software you are working on from 10 years. You need to deliver no matter what and how!

No one really cares if the product is thoroughly documented, or if we are deviating from the plan we set few weeks ago, or if the quality of the code is equivalent to a Michelangelo’s sculpture. What everyone should care about is to please the customer by delivering the product he needs. Notice that I didn’t say the product he wants. Yep! Many times the customer (which could be internal to your own company) doesn’t really know what he wants or he is not able to convey it well. More often, we are not able to understand his or the business needs. That is why you need constant collaboration. Make sure you demo your software regularly and accept any feedback. If need be, scrap code and tell your developers to not grow attached to it.

Also, keep in mind that delivering timely is fundamental to keep the executives engaged. Without support from the top layer, you go nowhere in the long run. If you want them to support you, you need to show value from the get go.

I know that change is never easy. It might seem logical that you take you longer to achieve your targets initially because of the learning curve. Please don’t create that mindset in the company as you are setting up everyone for failure. Expect things to work smoothly and, if they don’t, break any rule you just set. Don’t be stubborn, keep doing introspection and use your common sense!

So stop reading this and go work! Oh no wait! I have something else to tell you. Keep on reading 🙂

Do not estimate

Here is the bomb I need to drop.

Do not estimate! (in large groups)

If your teams spend hours estimating in story points and discussing for more than 10 seconds whether a particular story is worth 3 or 5 points, stop estimating! You are doing it wrong! It’s useless. Go work instead!

The reality is there is little value in an estimation you won’t be able to meet. Wait a second! It’s impossible to figure out if you are actually respecting the estimation as points are a relative measure. Well done! You managed to feed some b******* to the entire company and now you ended up with a system that can be easily exploited.

Don’t come and tell me I misunderstood how story points work or estimation. I understand their use and I know that if you have a skilled and motivated team they do wonders. But, and it is a big but, if you have an inexperienced, extremely large, or not-so-motivated team, everything will crumble and rather than achieving benefits you will end up with products that never see the light.

If your estimation sessions are taking forever, have your senior and experienced team members do estimation in small groups. Estimation is an art not science. The best bet you have to get a meaningful estimation is if you get it from someone who has worked multiple projects in different teams and contexts. The less people you put on it, the less costly estimation will be.

Nuke those meetings

How can you pretend people can achieve anything if their meeting schedule looks like this?

I will not spend too much words on this at it should be self-explanatory. However, I was positively surprised when I discovered that I share the same vision Elon Musk has on the topic. So, I am just going to quote an extract from an original email he wrote. You can find the entire email here.

Btw, here are a few productivity recommendations:

– Excessive meetings are the blight of big companies and almost always get worse over time. Please get of all large meetings, unless you’re certain they are providing value to the whole audience, in which case keep them very short.

– Also get rid of frequent meetings, unless you are dealing with an extremely urgent matter. Meeting frequency should drop rapidly once the urgent matter is resolved.

– Walk out of a meeting or drop off a call as soon as it is obvious you aren’t adding value. It is not rude to leave, it is rude to make someone stay and waste their time.

– Don’t use acronyms or nonsense words for objects, software or processes at Tesla. In general, anything that requires an explanation inhibits communication. We don’t want people to have to memorize a glossary just to function at Tesla.

– Communication should travel via the shortest path necessary to get the job done, not through the “chain of command”. Any manager who attempts to enforce chain of command communication will soon find themselves working elsewhere.

– A major source of issues is poor communication between depts. The way to solve this is allow free flow of information between all levels. If, in order to get something done between depts, an individual contributor has to talk to their manager, who talks to a director, who talks to a VP, who talks to another VP, who talks to a director, who talks to a manager, who talks to someone doing the actual work, then super dumb things will happen. It must be ok for people to talk directly and just make the right thing happen.

– In general, always pick common sense as your guide. If following a “company rule” is obviously ridiculous in a particular situation, such that it would make for a great Dilbert cartoon, then the rule should change.

I don’t think there is anything more I have to add for now.

Conclusion

My secret recipe for Agile, DevOps, and anything you intend to introduce in your company or team, is to use common sense. Rules are made to be broken. Break them when necessary. Do not focus on delineating incredibly strict and complex processes, as they hinder your productivity rather than foster it.

The most valuable resource you have in your company are the people. If you lack this resource, you have no chance of succeeding whatever approach you will use. Make sure to hire the right individuals and arrange them in teams that can actually take a product from inception to production.

Set clear targets and goals across all the organization. Expect those targets and goals to be met. If you accept failure as if nothing happened, failure will become the baseline in your organization and success the sporadic outlier.

Agile and DevOps are just means to trigger change within your organization. However, positive change can happen only through self-awareness. Dedicate time to identify what are the issues in your company and have everyone committed to solve those issues.

Engage your executives by delivering timely. Change is not easy and often causes friction. Without their support you will fall at the first obstacle.

Feel free to shoot me in the comments section 🙂

Thanks for your attention,

Marco