Saturday, November 14, 2015

Culture that accepts a slight risk of failure (NOT reckless failure) in the interest of being faster and more agile

Let's start with a few options:

(A)
Be fast, risk failure and if needed quickly recover to succeed.

(B)
Be slow and successfully launch.

Obviously the option A does NOT apply to companies that are building planes, ships, cars, medical equipment and what not. However, it does apply to a lot of other IT organizations.

In option A, I am NOT talking about recklessly failing. I am talking about leading a team and trusting them without watching every single line of code and without introducing too many gates during the development of a project. As long as you have professionals on your team, you really need to use "let the baby out of the crib" methodology and allow them to fall as they are learning to walk as a team.

When I say "fail", I also don't mean failing foolishly breaking every rule in the architecture book; that's being foolish and not fast. I am talking about the culture where risking normal failures is NOT looked down upon. It is all about keeping the levels of this risk within normal boundaries and that requires a skill.

This is what "Be Agile" could mean. Let's call it "The Function of Agility":

void beAgile()
{
    while(true)
    {
        developFast();
        allowRiskOfSlightFailure();
        quicklyCorrectIfNeeded();
        succeed();
        identifyWhatNeedsToImprove();
        applyWhatNeedsToChangeIncrementally();
    }
}


We don't need books and certifications. It just boils down to the above Function of Being Agile that we need to stick to; everything else is catering "Be Agile" approach to your company and it may mean that you implement what Scrum organizations put in place, or it may mean that you deviate from it in order to best achieve the goals in your work environment.

How do you gauge if you are on the right path?

It is simple. If the number of your failures is increasing over time and it is actually slowing you down, than you have to revisit the whole approach.

If the number of your failures is the same or less and you are not slowing down your development and deployments, then you are on the right path as long as those failures are not critical to the business. The goal is to keep iterating and NOT repeat the failures.

At the end of the day, if you have the culture that does NOT look down upon slight failures, your team will have so much fun which typically leads to amazing results. It is beautiful to watch the work in action. You can't really measure every step of the way, but what you can measure is how much more value you provided to your customers. That's the measure that matters at the end.


- almirsCorner.com - 

#agile #fast #flexible #BeAgile #SoftwareEngineering #SoftwareDevelopment #teamwork 


Monday, November 2, 2015

Amazon Web Services (AWS) Training - Some Info

I just recently attended a very good two-day training session on AWS. Jon Gallagher (our instructor) is very knowledgeable and good in painting the full picture on AWS. His labs were great too.

Here is the summary of the material covered in this training. We covered a lot in two days.
  • Introduction
  • Lab 1 - Installing AWS CLI & running some basic commands
    • get info on AZ-s
    • get info on EC2 instances
    • get info on S3 buckets
    • get info on SQS queues
    • get info IAM user and list the Groups
  • Security Policies
    • IAM users, groups, roles, S3 buckets permissions, VPC S3 endpoint, SQS permission
    • Sample JSON for a security policy
    • ARN (Amazon Resource Notation) 
  • Lab 2 - IAM setup (Identity & Access Manager)
    • create users
    • create groups
    • assign permission
    • create roles
  • EC2 Info   (Elastic Cloud Compute)
    • EC2 = Instance Type + AMI
    • Instance Type info
    • What is AMI
    • Hypervisor
  • Lab 3 - Working with EC2 from AWS CLI
    • get info on your VPC
    • get info on your subnets
    • create a public/private key to work with CLI
    • create a security group & add rules group
    • create/run an EC2 instance with pre-set AMI
    • SSH into your EC2 instance using the key
    • cURL command to your Hypervisor to get the meta-data
  • VPC & Networking
    • VPC info
    • Tribal knowledge on VPCs
    • setting up a VPC across a regions and multiple AZ-s
    • security layers to VPC and usage of public and private subnets
    • Security Groups as layer before Hypervisor and Hypervisor before you get to EC2
  • Cloud Scaling - EC2, ELB (Elastic Load Balacer) & ASG (Amazon Scaling Groups)
  • Lab 4 - Create Security Groups, AMI and ASG (Auto Scaling Group)
    • create multiple security groups
    • create an EC2 instance
    • create an AMI image from your EC2 instance
    • create an ELB (Elastic Load Balancer)
    • create an ASG (Auto Scaling Group)
  • Automation with CloudFormation
    • Structure of CloudFormation template (parameters, mapping, resources, outputs)
    • Output of one CloudFormation template can be used as input into another CloudFormation template
  • Lab 5 - Launching ASG with CloudFormation template
    • create a new stack in CloudFormation screen in AWS Console
    • load the CloudFromation template
  • Networking & VPCs
    • Default VPC vs. your own VPC
    • NACL to protect your VPC
  • Lab 6 - Building a VPC and ASG with Python Troposphere library
    • installing Python and all the libraries needed
    • running a provided Python script that sets up a VPC and an ASG
  • VPC Endpoints
  • VPC Flows
  • DynamoDB


Almir

#AWS #AmazonWebServices #cloud #CloudComputing #VPC #EC2 #ELB #CloudFormation #Python #Troposphere #Boto