Feeds:
Posts
Comments

Archive for June, 2017

It depends on what you are passionate about. I would choose passion over all other considerations or else you will burn out and the money won’t help. Any position you pursue in tech is going to require your complete dedication to achieve success.

However, I think the DevOps area has a lot of growth potential in the future. While I cannot speak to your interests I can tell you why I am drawn to the field after being a web based software developer.

I have learned through that if you are operations staff you’d better be automating your job, and if you are a developer you have to face the inevitability of getting down and dirty with operations if you are to stay relevant. Developers who won’t administer/monitor and admins who won’t develop will increasingly become less and less valuable to organizations needing to stay competitive.

DevOps is exciting because you are always working with and integrating new technologies and solving new challenges. Essentially your job is to find a happy balance between operations and developers. This relationship is delicate and can blow up if not regulated. As a devops specialist your job is to integrate these two different mindsets. This requires that aspects of IT be securely shared so that you don’t have the blame game. Developers need to continually push code and operations want to keep everything running smoothly. The more integrated the systems and processes in use, the easier it is for each to do their job.

I personally like to think of IT as three separate phases that all contribute to the ultimate success of the enterprise tech ecosystem; packaging, automation, and scaling.

Packaging:

DevOps is great if you like to explore and work with a variety of technologies and processes. I think one of the first things to consider is the packaging of IT that the tech teams use to provide the organizations products and services. The better packaged and more malleable the packaging the easier it is to keep everything standardized and reusable.

If you like playing with configuration management systems (Puppet, Chef, Ansible, etc…) and digging into imaging systems such as Docker you will like DevOps. I would caution that it is very important to create highly configurable packaging of the IT systems in use so that they can evolve as the organization’s needs change. This also makes it easier to modify for production, QA, staging, and development environments.

If you think about it, the amount of new technologies and services being released into the market is growing exponentially (especially with the add-on potential of all the open source frameworks in existence). In DevOps no technology is off limits and you find yourself continuously working with, integrating, and automating different technologies. As the amount of tech and services grow, so is the demand for people who can put it all together into golden images (configuration managed images on different environments).

Automation:

Your automation potential is only as good as your ability to package the infrastructure in a form machines can work with effectively. If you come from a development background you most likely have had to deal with brittle environments (at least in testing new technologies, which you should be continuously doing).

The DevOps specialist makes it easy for programmers and operations to automate their jobs so that we don’t have to reinvent the wheel over and over again. Ultimately, if the automation is good enough we can realize a scalable architecture (which is the end goal).

You should like scripting a lot. You don’t need to be the best programmer to accomplish this but the more integrated your approach the easier it will be to build on your previous work (which I like). Automation brings the machines to life and if you like seeing a bunch of moving pieces come together to achieve some measurable outcome you will like this part of the job.

I would recommend that you know at least one glue language: Python, Ruby, Go, etc. The more flexible the language, the better. Although, the beauty of automation is that many different languages can be brought together to create a unified system. If something needs to be built for speed, it’s easy enough to design that part in a language like C or Go while allowing other tasks that need more flexibility to be written in a higher level language. You definitely want to become very good at shell scripting which many times ties everything together.

I personally cannot see automation becoming less in demand in the future. The promise of the cloud is built on automation, and enterprise usage of the cloud is growing rapidly throughout organizations of all sizes and types.

Scaling:

If reusability is a passion of yours, I think you would definitely like DevOps. I believe the biggest factor in the successful tech organizations of the future will be their ability to scale rapidly while being able to deflate when not needed to minimize costs in downtime. Customers want speed. They don’t care about the tech behind the application as long as the application is reliable, zippy, and meets their needs.

If you can create packages of IT that can be easily automated in a portable fashion then I think you will have great prospects in the tech world in the future. Companies like Google and Facebook would never have gotten as popular as they are if they had not learned to scale their IT effectively.

Scalability is not easy to achieve and many would rather not have to worry about it, which explains the growth of scalability as a service offerings. But somebody has to know how. Think about the problems of the future: Data analysis, AI, internet of things, mobile consumption, scalable web driven apps, etc. While all of these tech areas require different skills to develop on their own, each is absolute garbage without the same fundamental building blocks. Want to jump from mobile to AI? DevOps could allow that. Want to play with that new SaaS service that is all the rage these days? DevOps can allow that.

DevOps is about being the glue that holds everything and everyone together, and to me that is what makes it so exciting. The possibilities are limitless and the technologies are always growing and evolving. And if you don’t focus on DevOps, you will still have to manage infrastructure as a developer anyway.

When I first started programming I started with a passion for machine learning in C, then over time I started creating web sites using asp.net for my organization. Over time I felt suffocated by the limited nature of the technologies people expected me to work with day in and day out. It wasn’t that I did not like the technologies, but I felt like I was in single technology hell. And once you gain a lot of experience in a specific technology or system people just expect you to focus on that area: recruiters, managers, developers, everyone. With DevOps variety is part of the job description so if you ever feel trapped by technology and find yourself looking to the stars wondering what the hell did I get myself into, DevOps can free you from that limited mindset.

That is why I got into DevOps. I certainly don’t claim to be the best or the most experienced out there, but I am a heck of a lot happier these days. And I am constantly learning new things that I can apply to any new project, whether it is a new AI platform or a mobile application.

At the end of the day your happiness and the passion you feel for what you do is all that really matters.

Read Full Post »

Measuring Agile Maturity

There are many efficient way to measure the maturity and performance of an agile team and one of them is by measuring cycle time. In a traditional project, we have the project cycle time, which is the time between start of the project and the final delivery or release. In an agile project, the cycle time can be measured on the level of user stories.

Lean: The above reasoning is supported by two main principles of a lean mindset:

Reducing cycling time is one very important principle of a lean mindset: we get faster feedback and test results, we prevent work from clogging our development queues and we improve morale because the team sees that the work ‘disappears’ faster from the backlog.

‘Avoiding waste’ is the primary objective of a lean approach. Any wait time between the different process steps can be considered as waste. Reducing the wait time can therefore be considered as a good way to get rid of ‘waste’, and also reduces the overall cycle time.

How to measure: The following image shows a simplified view of the life cycle of a user story in an agile project, including the potential wait times:

Measuring Agile Maturity 1.gif

The cycle time is the time between ‘Ready to Start’ and ‘Release’. This time can be significantly reduced by reducing the wait times (WT1, WT2 and WT3).

Depending on how we organize our sprint backlog, we can start by noting on each user story card the date on which the story became ready for development by our agile team. This might be the start date of our sprint.

As soon as we meet all the ‘definitions of done’ for that particular user story, note the actual date again on the story card. The difference between the two dates is the user story cycle time.

How to calculate the average cycle time: At the end of each iteration, calculate the average of the cycle times and divide the result by the average complexity of the user stories of the sprint.

The result of this division gives us the average cycle time of that particular sprint. The division by the average complexity is necessary to standardize on complexity.

Over time, when our agile team matures and becomes more efficient, we should see a decrease of the average cycle time. If this is not the case, then we are doing something wrong, and there are probably some bottlenecks in our process that we want to resolve.

Advanced mode: Cycle time variance: Reducing cycle time is one thing, but what about cycle time variance?

Let’s see these two different cycle time-related metrics on a graph:

Measuring Agile Maturity 2.png

The red curve show the distribution of cycle times of team 1, whilst the green curve shows the distribution of cycle times of team 2. The green team has a higher maturity level because of two reasons:

  • The mean/average cycle time CT2 is smaller than the mean/average cycle time of team 1, CT1.
  • The standard deviation of the measured cycle times of team 2 (B) is smaller than the standard deviation of the cycle times of team 1 (A).

This means that over multiple sprints or projects, team 2 is able to produce better predictable output.

Why cycle time is the right indication for maturity:

  • It focuses on the final goal (customer value) and not on the process (the customer does not care).
  • It is very easy to collect the relevant data.
  • It is a very simple and understandable metric.
  • We do not need additional tools, only a pencil and a calendar.

Read Full Post »