Is Going Agile Too Expensive?

I have heard the argument that agile is a con. A way to get the certification industry money and a case to get high paid consultants to fill their coffers.

I don’t think this is true for the simple reason that if you look and you don’t have to look hard, you can find resources to learn agile techniques for free. The way I see it, most agile methodologies such as scrum and Kanban are like open source. Free to use, but if you want more support you can pay for it.

For example, with scrum, you do not need to get a CSM or PSM to practice scrum. You can download the scrum guide for free. Learn from blog posts, videos, podcasts and do your own practice. If you want more support, then you can buy books. Still need more, do a course, still need more then bring in a consultant, Even if you do a training course or bring in a consultant, you still have to do the work. There are no short cuts.  The concepts of Agile simple simple, but they not easy.

As for the perceived requirement that you need a certification. Well, that started by a requirement by businesses. Not the people who developed the methodologies in the first place. A lot of businesses generally do not want to invest in their people. They are more likely to buy or rent expertise already than grow internally. They will try any shortcut whether or not it works in the long term. What better way to know if someone knows Agile or any other technology/methodology than to have them certified in such technology/methodology. People see the requirement, get certified so they can be hired. Right or wrong this becomes a vicious cycle that feeds itself and creates the requirement for certification. 

If you or your company is serious about being agile. Not for the kudos or bragging rights, but just to be better, I suggest learning the history, reasons and purposes behind the methodology.

The following resources both from a google search and my own resources should be of help.

Free Resources


Conference Videos

Software Houses

There are software companies that want to share their methods, help people learn.

  • Mountain Goat Software
  • Atlassian (Yay and Aussie Company)
  • Most tech companies have a blog where they share their development methodology which is usually some form of agile.

Web Sites

Pod Casts

Paid Resources


This set of books is specifically not Agile related, they deal with Lean and TPS and learning from mistakes. Agile/scrum have their roots in Lean. Agile is also a learning methodology, and to learn, you have to make mistakes.

Online Courses

This is only a handful of resources, there is probably a billion other resources out there that are free or cheap that will help you learn any type of agile methodology that takes your fancy.

I’m always interested in learning new sources. If you have a favorite free or cheap learning resources, please add them in the comments.


I myself have gone through the Certified Scrum Master course. I had done this after spending about a year learning about Agile and DevOps using some of the above resources.  I did the course because I wanted the alignment of what I had learned myself, and unashamedly the piece of paper.

My Views On Automation

One of the things I like doing at my job is automating repetitive tasks. For example, when a particular error occurs as part of the morning health check, an email needs to be sent out to the business owners of the source application (I work in middle ware) to notify them of the situation. (I know I’m doing it wrong – Special Cause/Common Cause, Burn’t toast etc – but that’s the situation I’m in) the process was to manually, so extract the relevant data, compose and email and send it out. All in all, about 5 minutes worth of work. Not long in the grand schema of things, but very boring. So I automated it. Now an email gets sent out automatically every morning. We don’t have to worry about it anymore.

Now, many times when you want to automate a task, there is the argument of “is it worth doing or not” comes up. In the above example, we are saving a task that only took 5 minutes a day. How long should we spend automating this task. 1 hour, 4 hours, 1 day, 1 week? (For the record, it only took me about 20 min for first version, then about another 20 min over several days to get the formatting right) for something so trivial.  Then again, lets look at another scenario. Say you have a task that will take you 5 min to do. But to after automating it, the automated process itself takes an hour. Not the writing of the process, but the actual execution. Should it have been automated?

In both these cases, there are arguments against automation because the time involved to either build or run the automation take too long. In my view, you are looking at the wrong metric.

My view is that automation should be used primarily for consistency. Spending a day on writing an automated script that saves 5 min will mean that that process will be run consistently forever and a day. The secondary benefits are that you don’t have to worry about the process any more – at least until it is no longer required. You have the knowledge on how it was automated which can be applied to automating future tasks. Finally, if you are lucky, the task may run quicker.

The same goes for a task that takes 5 minutes manually, but 1 hour automatically. You have the primary benefit of having the task consistently done.  Human error has been removed.  If the task needs to be done in a quicker time, then spend the time optimizing the automation script.

Now,  there are always exceptions to this rule, there always is. You have to use good judgement as to when to and when not to apply the rule.

Now, how do you determine what priority to automate. I’m not taking here as a manager (I’m not one) but as a person doing the manual work. Well, I work on one simple question. “What annoys me the most at this point in time?”.  I then spend time outside of my normal tasks trying to make that process better. Then I repeat. For the more common tasks, they get fixed pretty quickly. If they are not fixed properly, it annoys me and I go through the process again. For tasks that have long periods between them, I start working on them, I may not finish, but I document what I have found for the next round the task occurs and then work on it a bit more then.
The benefit of doing the “What annoys me at this point in time?” is that it is something that directly affects me. It becomes personal and thus I’m more likely to fix it. That is not to say that management cannot assign improvements, but generally, they are not the ones doing the daily work, and therefore do not see the pain points.