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?

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

In the Lambda console panel, create a new Lambda function. Set the name to be whatever you want it to be.

For the code of the Lambda function, copy and paste the handler.js file.

After you have created the function, select add event sources for the Lambda function.

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

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: