Browsing Category

Career

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 7

August 8, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

Several cases of Agile adoption in a set of big and mid-size companies. Also presented key benefits, challenges and outputs of an agile adoption

The content

Today, over 50% of the Fortune 500 companies from the year 2000 no longer exist. GE is stumbling. BlackBerry (RIM) is gone, and so is most of Nokia, raised to a $150 billion corporation. (…) John Boyd developed a methodology for operating in such situations, called the OODA Loop. The speed of executing the loop is the essential element of survival. It involves testing one’s premises by actual Observation, Orienting your corporation with respect to the situation. Then Deciding on a course of action, and then executing that plan by Acting. This is the meaning of being Agile. (…) Data is the new gold.

MIT – Cloud & DevOps course – 2020

Agile Adoption

Pros of agile software development:

  • Customers have frequent and early opportunities to see the work being delivered and to make decisions and changes throughout the development of the project.
  • The customer gains a strong sense of ownership by working extensively and directly with the project team throughout the project.
  • If time to market is a greater concern than releasing a full feature set at initial launch, Agile is best. It will quickly produce a basic version of working software that can be built upon in successive iterations.
  • Development is often more user-focused, likely a result of more and frequent direction from the customer

Cons of Agile Software Development:

  • Agile will have a high degree of customer involvement in the project. It may be a problem for some customers who simply may not have the time or interest for this type of participation.
  • Agile works best when the development team are completely dedicated to the project.
  • The close working relationships in an Agile project are easiest to manage when the team members are located in the same physical space, which is not always possible.
  • The iterative nature of Agile development may lead to frequent refactoring if the full system scope is not considered in the initial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.

Managing Complexity of Organizations and operations

As companies grow, their complexity grows. And they have to manage that complexity, otherwise, it’s gonna turn into chaos. The problem is that they usually manage that putting processes in place: you have to sign X docs, follow Y procedures, etc. The problem is that we tail employee freedom, and the side effect is that the high performing employees tend to leave our company.

Netflix’s solution to this scenario was different. They decided to let the smart workers manage the complexity instead of putting processes in place.

The problem for the traditional approach is that when the market shifts we’re unable to move fast. We have had so many processes and fixed culture that our teams won’t adapt and innovative people won’t stick to these environments.

That leads us to three bad options of managing our growing organizations:

  1. Stay creative and small company (less impact)
  2. Avoid rules (and suffer the chaos)
  3. Use process (and cripple flexibility and ability to thrive when the market changes)

Back to Netflix case: they believed that high performing people can contain the chaos. With the right people, instead of a culture of process adherence, you have a culture of creativity and self-discipline, freedom, and responsibility.

Comparing waterfall and agile software development model

Source:

Exercises and Assignments

  • Assignment: Write a summary about two articles suggested by the MIT that highlight the complexity of turning Agile that some companies faced and how they are thriving.

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 6

August 2, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

Introduced the serverless paradigm, pros and cons, limits and the evolution to reach it

The content

  1. Serverless computing is a Cloud-based solution for a new computing execution model in which the manager of the server architecture and the application developers are distinctly divided. A frictionless connection exists in that the application does not need to know what is being run or provisioned on it; in the same way that the architecture does not need to know what is being run.
  2. The journey that led us to serverless (image below).
  3. A true microservice:
    1. Does not share data structure and database schema
    1. Does not share internal representation of objects
    2. You must be able to update it without notifying the team
  4. Serverless implications:
    1. Your functions become Stateless: you have to assume your function will always run a new recently deployed container.
    2. Cold starts: since every time your function will run in a new container, you have to expect some latency for the container to be spun up. After the first execution, the container is kept for a while, and then the call will become a “warm start”.
  5. Serverless pros:
    1. Cloud provider takes care of most back-end services
    2. Autoscaling of services
    3. Pay as you go and for what you use
    4. Many aspects of security provided by cloud provider
    5. Patching and library updates
    6. Software services, such as user identity, chatbots, storage, messaging, etc
    7. Shorter lead times
  6. Serverless cons:
    1. Managing state is difficult (leads to difficult debug)
    2. Complex message routing and event propagation (harder to track bugs)
    3. Higher latency for some services
    4. Vendor lock-in
  7. More on serverless: https://hackernoon.com/what-is-serverless-architecture-what-are-its-pros-and-cons-cc4b804022e9
From monolith to serverless journey

Exercises and Assignments

  • Assignment: Deploy an existing application to AWS using Lambda and DynamoDB to show a Pacman Game. A few screenshots below:

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 5

July 22, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

Introduced the regular high-ground phases of a Digital Transformation (and cases for exploring them), which are:

1 – Initial Cloud Project

2 – Foundation

3 – Massive Migration

4 – Reinvention

The content

  1. Cloud computing services are divided in three possible categories:
    • IaaS – using the computational power of cloud computing data centers to run your previous on-prem workloads.
    • PaaS – using pre-built components to speed up your software development. Examples: Lambda, EKS, AKS, S3, etc.
    • SaaS – third-party applications allowing you to solve business problems. Examples: Salesforce, Gmail, etc.
    • XaaS – Anything as a service.
  2. An abstraction of Overall Phases of adoption:
    • 1 – Initial Cloud Project – Decide and execute the first project
    • 2 – Foundation – Building blocks: find the next steps to solve the pains of the organization. Provide an environment that makes going to the cloud more attractive to the business units. Examples: increase security, increase observability, reduce costs.
      • 1st good practice: During this phase, you can create a “Cloud Center of Excellence” committee to start creating tools to make the cloud shift more appealing to the rest of the organization.
      • 2nd good practice: Build reference architectures to guide people with less knowledge.
      • 3rd good practice: Teach best practices to other engaging business units.
    • 3 – Migration – Move massively to the cloud
      • One possible strategy is to move As Is and then modernize the application in the future (the step below).
    • 4 – Reinvention – modernize the apps (here you start converting private software to open source, Machine Learning, Data Science, etc).
    • See the picture below for an illustration of these 4 steps:
Phases of Digital Transformation, and time and value comparison
  1. The pace of adoption is always calm. Even for aggressive companies, like Netflix that took 7 years to become a cloud-first company.
  2. Microsoft case (highly recommended read):
    • Principles for their “shift left” on number and coverage of tests:
      • Tests should be written at the lowest level possible.
      • Write once, run anywhere including the production system.
      • The product is designed for testability.
      • Test code is product code, only reliable tests survive.
      • Testing infrastructure is a shared Service.
      • Test ownership follows product ownership.
    • See below two pictures of (1) how Microsoft evolved their testing process model and (2) the results they achieved.
1 – How Microsoft evolved its testing model
2 – Microsoft results
  1. Layers of test (based on Microsoft example):
    • L0 – Broad class of rapid in-memory unit tests. An L0 test is a unit test to most people — that is, a test that depends on code in the assembly under test and nothing else.
    • L1 – An L1 test might require the assembly plus SQL or the file system.
    • L2 – Functional tests run against ‘testable’ service deployment. It is a functional test category that requires a service deployment but may have key service dependencies stubbed out in some way.
    • L3 – This is a restricted class of integration tests that run against production. They require full product deployment.
  2. General Electric unsuccessful case:
    • GE failed because, despite having created a new unit for the digital transformation initiative, it inherited the culture of the GE Software.
    • Why digital transformation initiatives fail?
      • Lack of business focus.
      • Lack of alignment of plans and practices between the new and the legacy.
      • Not empowering developers.
      • Not experimenting.
  3. Netflix case:
    • Netflix introduced Chaos Engineering techniques: 
      • The best way to avoid failure is to fail constantly
      • The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most in the event of an unexpected outage
    • Simian Army is the evolution of the Chaos Monkey.

Exercises and Assignments

  • Assignment: Create a self case study containing the given structure:
    • Brief description of the company (attaching web link if possible)
    • Introduction
    • Description of the company’s challenge
    • Solution/Project stages/Implementation
    • Risks
    • Mitigations
    • Conclusion

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 4

July 14, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

The DevOps revolution: importance of continuous feedback, data-driven decisions, pillars of DevOps and metrics

Main quote

Today, software development is no longer characterized by designers throwing their software ‘over-the-wall’ to testers repeating the process with software operations. These roles are now disappearing: today software engineers design, develop, test and deploy their software by leveraging powerful Continuous Integration and Continuous Delivery (CI/CD) tools

MIT – Cloud & DevOps – Continuous Transformation course – 2020

The content

  • DevOps key metrics to be watched:
    • Delivery lead time (measured in hours) – e.g.: how much time is taken between the task registered on the management tool until it reaches production?
    • Deployment frequency – how many deploys to the Production environment we make weekly.
    • Time to restore service – how many minutes we take to put the service back to work when something breaks.
    • Change fail rate – how many of our deploys to the Production environment cause a failure.
  • Importance of information flow. Companies have to foster an environment of continuous feedback and empowerment. It allows everybody to solve problems and suggest innovation within their area of work.
  • Data-driven decision making
  • Pillars of well designed DevOps:
    • Security
    • Reliability
    • Performance Efficiency
    • Cost Optimization
    • Operational Excellence
  • A good example of a well-designed pipeline abstraction:
    • Version control – this is the step when we retrieve the most recent code of versioning control.
    • Build – building the optimized archive to be used to deploy.
    • Unit test – running automated unit tests (created by the same developer that created the feature).
    • Deploy – deploy to an instance or environment that allows it to receive a new load of tests.
    • Autotest – running other layers of the test (stress, chaos, end to end, etc)
    • Deploy to production – deploy to the final real environment.
    • Measure & Validate – save the metrics of that deploy.
  • There are companies that are up to 400x times faster on having an idea and deploying it to production than traditional organizations.
  • Several analogies between Toyota Production system and cases (below) and DevOps:
    • Just in Time
    • Intelligent Automation
    • Continuous Improvement
    • Respect for People
  • Theory of Constraints:
    • You must focus on your constraint
    • It addresses the bottlenecks on your pipeline
  • Lean Engineering:
    • Identify the constraint
    • Expĺoit the constraint
    • Align and manage the systems around the constraint
    • Elevate the performance of the constraint
    • Repeat the process
  • DevOps is also about culture. Ron Westrum’s categories for culture evolution:
  • Typical CI Pipeline:

Exercises and Assignments

  • Assignment: Creating a CircleCI automated pipeline for CI (Continuous Integration) to checkout, build, install dependencies (Node app) and run tests.

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 3

July 7, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

Docker, Containers Orchestration and Public Key Infrastructure (PKI)

The content

  • How the stack of software components used to run an application got more and more complex when compared to past years.
  • In past years a huge number of web applications used to run on top of LAMP (Linux, Apache, MySQL, and PHP/Pearl). Nowadays we have several different possible approaches for each one of the layers of this acronym.
  • Containers are the most recent evolution we have for running our apps. They followed these steps:
    1. The dark age: undergoing painful moments to run your app on a new machine (probably using more time to run the app than actually writing it).
    2. Virtualizing (using VMs) to run our apps, but having the trade-off of VMs’ slowness.
    3. Containers – They are a lightweight solution that allows us to write our code in any operating system and then rerun it easily in another operating system.
  • The difference between Virtual Machines and Docker:
    • Virtual Machines = Applications + Libraries + Operating System.
    • Docker = Applications + Libraries.
  • The analogy between the evolution of how humanity solved the problem of transporting goods across the globe using containers (real and physical containers) compared to how software developers used the containers abstraction to make our lives way easier when trying to run an application for the first time.
  • Kubernetes is introduced and the benefits approached:
    • Less work for DevOps teams.
    • Easy to collect metrics.
    • Automation of several tasks like metrics collecting, scaling, monitoring, etc.
  • Public key infrastructure:
    • More and more needed interaction machine-to-machine requires more sophisticated methods of authentication rather than user and password.
    • Private and public keys are used to hash and encrypt/decrypt messages and communications.

Exercises and Assignments

  • Exercise 1: Running a simple node app with docker (building and running the app)
  • Assignment:
    1. Build a docker image
    2. Publish it to dockerhub.com
    3. Run a local ghost blog using docker
    4. Publish a sample post 

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 2

July 1, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

The course has two big parts: (1) technical base and (2) business applications and strategies

The second module introduces benefits, trade-offs, and new problems of developing applications for scaling. It also covers the complexity of asynchronous development.

One more technical assignment is present, and it’s based on Node to focus on Javascript since it’s the most used programming language nowadays.

The content

  1. To start with, they approached the whole web concept (since its creation by Tim Berners Lee).
  2. The Javascript creation (the most used language for web applications worldwide).
  3. How Google changed the game creating Chrome and the V8 engine.
  4. The creation of Node.JS.
  5. Implementing a simple webserver at Digital Ocean.
  6. The evolution of complexity between the web first steps and the day we are right now: Open Source, JSON protocol, IoT and Big Data and Machine Learning more recently.
  7. The world of making computation in an asynchronous world/architecture.

Exercises and Assignments

  • Exercise 1: forking a project at GitHub.com and sending a pull request back.
  • Assignment 1: Running a simple node application locally (a PacMan game) to understand the communication between the client (browser) and server (Node.JS), and also retrieving metrics through an endpoint using JSON as a communication pattern.

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

@MIT, Career, IT is business

@MIT: Cloud & DevOps – Part 1

June 27, 2020

@MIT series is a group of articles being written to describe my learning path attending to the Cloud & DevOps: Continuous Transformation at the MIT.

This article at a glance – TL;DR

The first module is putting everybody’s knowledge up to date about the internet and software development practices evolution.

Assignments of the first module are simple when technically speaking

The content

Disclaimer: I won’t post the course content and deeper details here for obvious reasons. Everything mentioned here is my learning and key takeaways from each class/content.

The first module is very introductory. Concepts like the internet creation and explanations about how the information flow evolved from the first internet connection to the cloud are approached very briefly.

More than being introductory, it is very straightforward and hands-on (which I consider great). There are forum discussions for the participants to get to know each other, and an open Q&A about the exercises and assignments.

Exercises and Assignments

  • Exercise 1: examining a small JSON file at the Chrome console to understand the JSON pattern and Javascript key concepts.
  • Exercise 2: examining a BIG JSON at the Chrome console to show how things can get complex eventually.
  • Exercise 3: running a Node simple app to analyze the BIG JSON file from exercise 2.
  • Assignment 1: Creating a simple static personal website at Amazon using S3 buckets. My result is here: https://guilherme-mit-module-1.s3.amazonaws.com/color.html
  • Assignment 2: Creating a simple static personal website at GitHub.io. For this one, I went a bit further and added a small set of free static CSS and HTML pre-built to reach something better than just the “hello world”: https://guisesterheim.github.io/

Resources

All the resources used to reach the results above are stored in this GitHub repository: https://github.com/guisesterheim/MITCloudAndDevOps

Career, Entrepreneurship, IT is business, Practical examples

Two main errors your agile project may have right now and how to solve them

March 12, 2020

Doing agile for software development is way beyond leaving the heavy documentation behind and produce more. According to an HBR study of 2018, 25% of enterprise companies are already using agile and 55% are in the process of doing the same. The data doesn’t lie: the masters of DevOps and Agile grow and are 60% more profitable than the rest. Agile brings many benefits, but it also brings new challenges built-in. The single point of adopting agile is already a major challenge. But after them, new challenges are still there and you might not have noted them.

1st – Involuntary blindness from POs

A day in the skin of a PO (Product Owner) is tough. They own the product! And are responsible for its evolution. Basically they are responsible for translating the company’s macro strategy for that product into the actual final product. It sounds pretty simple, but this process is where commonly things get fuzzy. A PO also:

  • Solves questions from the development team on their tasks;
  • Keeps feeding the backlog;
  • Helps the Scrum masters with decisions for prioritization;
  • Eventually, changes prioritization and delivery plans because of special requests from the management;
  • Monitors metrics of the product;
  • Is responsible for meetings with high management to discuss the metrics she’s been monitoring;

Many of the items above would require a person full time working to fulfill it successfully. But given this load of work, the PO often leaves behind one important thing: hearing what the market is saying and still staying aligned with the macro strategy. By that I mean the PO frequently doesn’t have time to think, judge and decide appropriately after a new demand came from a BA (Business Analyst) or high management. Due to lack of time, she leaves behind the most important task of his job, which is enhancing the product. Let’s go over one example to better illustrate:

A page never used in a hotel website

Years ago I was the SM (Scrum Master) leading a team developing a hotel website. I remember as if it was today. We had a big deliver at the end of 3 months and in the last week, my PO brought me the news that we missed one important page to showcase the hotel’s partnership with an entertainment channel. Guess what? We worked several hours more than planned and delivered just a small part of that page. Also kept working on the same page even after the deadline. We released the final page a few weeks later, and I was checking Google Analytics. I found out that that page had less than 5 percent of the website visits.

The summary: we spent at least one entire month of work on a page that less than 5% of our target public was actually interested in. We wasted one month of money for a team with 4 dedicated people. There was no regulatory thing and no contract binding forcing them to have that page live. It was just a request from a board member. In that situation, the PO SHOULD have argued about not doing that and going for the e-commerce system as a priority. This was actually something the users were asking strongly.

But why did the PO let it stay that way? The answer: she didn’t know that page was about so few accesses. She was so dived into the deadline and reports and monitors and tests that she just accepted the request without questioning it. If she had had time to think about it, with the appropriate information from her BAs, she would have taken a better decision.

2nd – Deficient hands-off of tasks from the PO/BAs to the delivery team

The second thing that often breaks plans is when the planning meeting is already going on and the technical team finds out a task is much bigger than the PO/BAs thought at first. When the PO is defining the next tasks for the backlog, she must be well aligned with the software architects. When a major feature (an epic) comes to the table, the technical team has to adapt the software to develop that new task accordingly. Let’s go over one more example:

The “just one more report”

This one happened during a project for one company in the manufacturing industry. The software had been running for months and was stable. We were in a phase of acting over bugs, security and small features. We were also generating some reports for gathering new metrics. When the planning started, our PO explained about the task of adding more columns and creating a new report with charts. The charts were fine, but those new columns were stored in other systems which we didn’t have control over. We had to talk to people on the other software to create an API for us to consume the data, and the simple report took more than a month to be finished.

The interesting part of this example is that the report was promised to be delivered after one week and took almost 2 months. The management had to wait for the new report to take new decisions because of the important information. The change from 1 week to ~2 months created an unneeded discussion between the project team and the management. All of that wouldn’t have happened if somebody with a brief technical vision of the project was involved during the grooming/prioritization of the backlog and had properly communicated with management.

If a task much bigger comes with no previous preparation, it generates delay. The way to solve it is to have technical senior people checking the backlog periodically and being closer to strategic decisions. This way they will be able to anticipate such moves and tackle big tasks little by little.

At last

Agile is not exact sciences. You will have to find your own set of practices that will create your own agile. These are the two main challenges I found are often hidden and people don’t actively tackle them because they don’t hurt at first, but yes have side effects that can turn into a big mess. And what are your main challenges?

Career, Practical examples

6 steps for the best feedback you’ll ever give

November 19, 2019

After some years leading IT teams and dealing with many different scenarios, I’ve been refining the techniques for giving a good feedback. A good feedback session usually has just the last 4 steps written here.

But something happened last week and made me add two obvious steps that are often forgotten before the actual feedback session. Just because giving good feedback is way easier, here I present the steps to give feedback when you need to talk about behavior, a mistake, or even to have a regular talk to help somebody with their career progress.

1 – Build trust

A trustworthy environment is the base for a good feedback moment. There’s an exchange between the one who gives and the one who receives feedback. Who gives it learns and gets experience. Pretty often understands how and why things are going the way they are going, and then has the opportunity to adapt and evolve together (this is part of the leader mission btw). The one who receives the feedback is thirsty for evolution and progress on their career. Usually seeks feedback for improvement constantly. But what if they don’t trust each other? Who gives feedback gets afraid of self-exposure. Fears not being enough to make things happen and help to develop the other side. And who receives feedback easily dives into an ego that will make the suggestion for improvement sound something unreal.

The trust between the two parts is crucial. Do you have trust within your team? Is talking to each one of your team individually part of your routine? Do you enjoy to stay together? Does your team come to ask you a point of view or advice when something goes wrong? Do you back them up when things go wrong or do you expose them? Do you feel like you accomplish stuff together? If the answer is no to a few of the questions, my guess is you don’t have a trustworthy environment.

2 – Set the goal

Since now you have trust, it’s time to together plan how far, how, and why the feedback receiver wants to go. What do they aim? This is the core of what will motivate them. The side missions can be something close to the goal, but the big missions must always be something clearly pointing to the individual goal. As a leader, it’s your duty to understand even if the individual will evolve more with another leader than would with you.

The key to this step is to always have a plan to follow. There is always stuff to be improved. What are the short, mid and long term goals for the one you are giving feedback? Does the feedback make sense when compared to the goals? Once you have the macro plan, SMART activities might help people see progress happening, depending on the team you are leading.

3 – Start with a good point

Ready for the real feedback moment? Why should you start telling something good? Starting by mentioning something the individual does well is a good way to start and to create empathy. You will be showing you recognize the good job being done besides the feedback you are about to give. It will increase the chances of the feedback to be received in a positive way, deeply understood and connected with real scenarios to help you explore the subject even more than what was planned.

4 – Show the FACT

Just show the fact. What happened? Was it a bad posture during a meeting? Was it a delayed task? Did they offend a colleague? Show the problem without judging. Do not make comments about what happened. Just say what has to be said looking in the eyes. It’s something important and has to be understood as a message. Straight.

The fact cannot be something you suspect. If you are not sure, it might be unfair. If you suspect and it’s a reality in your team, just pay more attention and you will see the thing happening. Go back to step 1 and get closer to your team if you don’t see it.

It cannot be something somebody told you. If you go for this way, there’s a huge risk of creating an environment of gossip. And then you’re back to the 70’s leadership style.

5 – Show the impact

Often people who commit mistakes don’t see or don’t want to see the impact. People don’t want to be seen as they are pulling the performance down. Why was the goal, delivery or whatever compromised by the FACT?

Was the fact a lack of commitment? The impact can be the delayed delivery and a bad relationship with your client (internal or external).

Was the fact an argument during a meeting? The impact can be damage to the team relationship.

6 – Build the action plan

You can create the action plan once the fact and impact are understood. What will prevent the same thing to happen once again? What happens if the situation occurs again?

For the action plan, you have to set SMART (specific, measurable, achievable, relevant and time-framed) goals. When you will check again if the issue was solved? If it’s not solved, another feedback session will occur, but if it was solved, it’s important to note and recognize the progress made.

Career, Practical examples

Communication issues? Maybe it’s engagement issues

December 24, 2017

I started thinking on this article as my self year’s end retrospective. And I realized the biggest thing I learned during this year regards engagement.

I’ve been hearing, for years, that “80% of the projects that fail, fail because of poor communication”. That’s a sad true, but this year I realized this is an easy but messy abstraction. When you say that communication is the problem, you are hiding many serious problems, not only in your project, but also in your organization. And after that eureka moment, a new one came: people do “communicate the proper way” if they are engaged and have support to develop themselves.

 

Some examples
  1. We have a contract to watch an online app. It’s not very critical, but we still have SLAs to accomplish when it’s down. Then one issue comes and the person from OPS forgets to tell the customer, during the first 15 minutes, that he’s looking for a solution. Beyond that, he takes one more hour to solve the problem, than the 4h regularly expected. It will cause an argument during a meeting between the managers and everybody will finish the subject saying that they had a communication issue;
  2. We evolve a very critical solution, that deals with money, to a customer. Then the developer didn’t create the automatized test and the app breaks when goes to production. It will cause an argument during a meeting between the managers, and everybody will agree that the QA guy didn’t communicate properly to the DEV guy about the missing test.
  3. The project manager tells the project is delayed, but doesn’t tell how much it is. When something goes bad and someone ask for it, he defends himself saying he told about the delay, and had an interpretation issue because those who read didn’t understand the message he wanted to say. Then after that meeting, everybody will agree that he haven’t communicated the right way;

 

Why these things happen

What I learned during this year, regarding engagement, was to identify why these examples happened:

  1. The person from OPS team didn’t tell the customer he was working at the first 15 minutes, and forgot to tell he would take one more hour to solve the ticket, because he was not well empowered of its position. He doesn’t understands his position. If he forgets to tell the customer about the down time, the customer won’t be able tell the users. The users will start calling the call center, and it will generate an overhead on the call center team. So at least 10 people will have more work to do, forcing the company to pay for that extra hours, because of one missing news. The person from OPS wouldn’t have forgot to tell anyone needed if he truly understood the scenario.
  2. The second example has nothing to the QA. The responsibility affects the developer. He hadn’t created the test because he doesn’t know that every one hour of that system stopped, makes the customer to loose US$ 10.000,00. Nobody, when old, will want to tell stories to their children like “hey, once I stopped the production environment, and screwed many people’s life”. So the developer was negligent about the test because he is not well empowered of its responsibilities and capabilities.
  3. The project manager will is not to hide information. He gets paid, essentially, to keep people informed. When he waits one or two months to say the project is delayed for 2 months, he doesn’t think the people from project will be needed in a next one, and it will cause a loss on the company. Since people won’t be available, the original project’s budget won’t be enough, and the whole company will spend more money to hire new people to the next one.

So if you are inside any of these examples, think on the other side as your true friend. Would you let, any of these examples to happen, if you knew how deep it would affect them?

 

Solving the wrong way

It’s easy to put all these problems inside one basket and label them as communication issues. Then, our technical minds will think about processes to guarantee that:

  1. The tickets system automatically send and email telling the customer we’re working to solve the issue;
  2. We will create an integration between the task acceptance tool and the code repository to check if all the tasks have at least one test designed;
  3. The project manager will always present the status report having the customer on it’s side, so no information will be missed again;

The suggestions above are not wrong and shouldn’t be faced as something to be avoided. But they must be the last alternative. They are all mending to lack of people engagement.

 

Solving the right way: build together

People tend to be good. When you share the right way their responsibilities and how their activities affect each other, they will feel inside the group and will always try to help everybody. So why not asking each one of the actors of these examples how they would solve the problem? Present the problem, tell everything that happened because of their behavior. How to solve? This is the most difficult part. Probably the first thing coming from them won’t be the perfect solution or the solution you thought. Then it’s time for to show a better solution and check if it makes sense to those who will put it in practice. A mix of the ideias can be a good start.

And now we talk about people’s maturity to solve problems:

  • If they are junior people with good potential, just letting them to know their responsibilities can solve the problem. They have good intentions! They won’t forget to tell anybody the next time about what’s happening;
  • If they are overwhelmed, you will advice about looking for self management tools. And also will help them to focus on what is important and not getting overwhelmed again;
  • If you realize its needed, why not using one of the process solutions described above as the wrong way? Take care because if must make sense to everybody affected. It depends on people maturity to not feel pushed;

 

The main goal is to look for a mindset of empowering and networks, as described on the image below:

 

Always have next steps

Once I was invited to join a retrospective. The goal was to help a team with an external vision so they could improve their processes. The first thing I asked was where the “next steps” of the previous retrospective were. For my surprise they weren’t.

Always keep track of goals and results. It gives you sense of improvement, and if it doesn’t it will be clear to find where new mistakes were made. Have a periodic checkpoint with each one of the scenarios above until it fits a track where the problems don’t happen again.

After that, when you have the whole solution, you will be able to share your good practice to other teams around you:

  • What happened; Why happened; When happened;
  • What did you do to solve it, what were the first trials, and what actually solved it?
  • What did you learn from it? Next steps;