I’ve been catching up on articles and podcasts about Agile development, and how “it’s dead”.

http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
http://www.jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html

Both articles talk not about how “Agile software development is dead” or “wrong” or “no longer hip” or any of that. It talks about the community misinterpreting and abusing the concepts of Agile (and Scrum).

Some stuff on what I feel is going on.

Absence of Method

The notion of “Agile = no planning”. I’m sure it has gone away quite a bit now, but I still hear about it. Agile doesn’t mean that you can just develop without any planning. In fact, I even believe that Agile requires a larger devotion to the process, more than traditional waterfall development.

Method Before Philosophy

I personally am also guilty of this - We hear sprints, iterations, daily stand-ups, retrospectives, and we decide to use them. But we forget WHY they exist.
Agile is philosophy of iterative/incremental development and frequent delivery. All other rituals, like those of Scrum, are just formats of how to execute on that philosophy.
If you can’t show your customer/stakeholer a (potentially) shippable product by the end of the iteration, something isn’t right. If majority of the duration of the project is being spent on planning rather than developing, something isn’t right.

Scrum master certificate

I believe that the Scrum Master certification is a good idea for people who already have had enough in-field experience with scrum, to get a deeper understanding. But I don’t think it works the other way around - If you haven’t had in-field experience, there is no way you will become a functional scrum master just with the few days of training. Scrum is learned in field with the different problems that come with different sizes/types of projects.
I believe there is a lot more commercial interest behind the Scrum Master certification.

My mission lately is to learn and enlighten my team on a more efficient and motivating software development. The answer surely isn’t blindly following Scrum methodologies, but it certainly is a start, so I want to do it right.

I wrote a Lambda script that let posts your Amazon CloudWatch alerts to your Slack.
I realized alerts by e-mail are kinda old-school already. In our company we never use e-mail internally anymore; The ONLY internal e-mail is server alerts.
So why not take that to Slack too?

Here it is:

https://github.com/ashiina/aws-lambda-cloudwatch-slack

lambda-cloudwatch-slack

Amazon Lambda to receive alerts from CloudWatch and post to Slack.

What is This?

It’s an Amazon lambda script that receives data from Amazon CloudWatch via, then posts that result over to Slack. Just configure the javascript file and set it in Lambda, then you are good to go.

How to Use

Alarm configuration

In handler.js, you will find ALARM_CONFIG, which is the config for your alarms. You can set different configs for different alarm conditions, depending on the subject of the CloudWatch notification.

Slack configuration

In handler.js, you will find SLACK_CONFIG, which is the config for you Slack. Set the correct values in this.

If you have trouble finding the above, Go here to set up your Incoming Webbhook integration for Slack,
https://api.slack.com/incoming-webhooks
Then find your Webhook URL. The configs will be:

https://{team}.slack.com/services/hooks/incoming-webhook?token={token}

Amazon CloudWatch configuration

Set whatever CloudWatch you want in your CloudWatch settings. Be sure to remember the SNS topic you send the alarms to.

Amazon Lambda configuration

1. In the Lambda console panel, create a new Lambda function. Set the name to be whatever you want it to be.
2. For the code of the Lambda function, copy and paste the handler.js file.
3. After you have created the function, select add event sources for the Lambda function.
4. In the event sources, select SNS and select the topic for which you’ve created on CloudWatch.

That is all. You should be receiving CloudWatch alerts on your Slack.

Testing, Debugging

When you want to debug/test your Lambda function, try using my lambda-local NPM.
It’s a command-line tool that let’s you execute Lambda functions on your local machine.
https://github.com/ashiina/lambda-local

License

This library is released under the MIT license.

I never could understand the reasoning behind the Monty Hall Problem. Well, I could understand the reasoning, but I couldn’t grasp the notion of how this can be true in real life.

There is a famous argument to this problem where it says “What if, right after the host opens one door, an alien appears from no where who has no prior information. Wouldn’t the probability for choosing either door be 50/50 for it?”. And I thought that was a very sound argument.

I decided to test it in real life with some python. Coincidentally this is Monty Python :)
So here’s my code:

https://github.com/ashiina/montyhall

Yep, and as expected, the simulation always gives me an result of a 66.6% chance of success - Not 50%.

$ python run_montyhall.py y 100
{'Wrong': 35, 'Correct': 65}

So it seems like I will have to just go with the reasoning here.
Interesting.