Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

The Early Days of Agility

Agile / Scrum

18 May, 2021

George Gatsis
George Gatsis

CTO / COO Consultant at ExecHQ

George Gatsis, principal CTO and COO at ExecHQ, remembers that revolutionary time in the industry when making teams more agile was the brand new cure-all for dysfunction in the workplace.

Problem

Like many people in software development, my tenure goes back for more than forty years. In the early days, you could often produce a product that is buggy as all hell, but that people will still consume it regardless.

At one point during these early days, I found myself walking into a situation that involved a relatively small group of thirty or so who would be on my development team. It was absolute chaos. It was a task-switching environment. The Head of Engineering would move the goalposts daily, changing the structures of the teams within the group almost constantly. People were being thrown from assignments and tossed around needlessly.

The disorganized environment led to faulty work, and, when a bug was found by the testers, the engineers would be upset. The situation was, unfortunately, very adversarial. Our deliveries were one to two years behind where we wanted them to be. The list of defects was always growing.

We were utilizing the waterfall style of working. This was right when agility was being introduced to the world of tech. We were eager to incorporate this new way of thinking into our model of business and development.

Actions taken

I read the Agile Manifesto when it first came out — I even happened to know one of the people who had signed it. I brought him in to speak about agility at a networking event that I had brought together.

They began with a process called Extreme Programming. It involves two developers working simultaneously on a single piece of code. The idea is that you cleanse the code as you’re writing it, because both developers bring their own unique perspectives to the project at hand. They see the others’ issues objectively, and, together, they end up producing something superior than what they would be capable of individually.

We began to adopt the principles that the manifesto outlined in our own company in order to solve the problems that we were having. We changed the process and programming languages that we were using and initiated a paradigm shift in the environment of the office. We relaxed many of our office policies like our dress code and we offered new flex options that allowed our employees to work comfortably, on their own terms. We began paying people on a project-output and quality basis that rewarded ability.

The release that followed all of these changes did, in fact, end up being late. But the product that we put out ended up being of a much higher quality than what we were doing before. Our beta customers liked the offering so much that they ended up championing and selling the product for us. Every release to follow ended up hitting its mark within a week or two. From stagnancy, we were able to scale up significantly.

Lessons learned

  • After having those experiences in the beginning, I started to pursue a policy of producing the highest quality of product possible. There is a false notion that says producing quality requires the investor to throw large sums of money at the project. Ironically, committing your efforts to producing something objectively worthy reduces costs by increasing productivity overall.
  • Agile, if you do it correctly, helps you to focus on what must be done in the present moment, as opposed to what you see as being necessary months down the road. The idea is that if you try to pre-plan all of that, you end up dismantling half of it. You might as well build something that is actually relevant when the time calls for it. In the past, when things weren’t changing so quickly, a waterfall type of approach worked to some extent. Now, you need to be agile in order to keep up. Locking down requirements will have you building products that will not be relevant to the markets that they end up seeing in actuality.
  • Integrated teams and integrated testing will increase the potency of your troubleshooting efforts beyond what independent testing can offer. The agile process amounts to much stronger production code in this way. Working in iterations that are reviewed frequently allows your developers to be more engaged with what they’re working to produce for the company. Your people become more excited about the project and will autonomously refine it.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

How to Build a Software Team from the Ground Up

12 November

Deepesh Makkar, Sr Director of Engineering at SunPower Corporation, shares his experience transitioning his organization from contractors to a 50/50 split of full-time employees and international vendors.

Hiring
Motivation
Cross-Functional Collaboration
Agile / Scrum
Deepesh Makkar

Deepesh Makkar

Sr Director of Engineering at SunPower Corporation

Choosing the Perfect Implementation of Agile

25 October

Shubhro Roy, Engineering Manager at Box, stresses the importance of the holistic nature of Agile methodology; picking and choosing à la carte may cause more problems than it solves.

Goal Setting
New Manager
Agile / Scrum
Shubhro Roy

Shubhro Roy

Engineering Manager at box

Optimizing With Scrum

13 October

Phillip Derosa, Global Director of QA at OneSpan, takes Scrum seriously; he knows that the methodology is only as effective as its implementation.

Goal Setting
Agile / Scrum
Phillip Derosa

Phillip Derosa

Global Director of QA at OneSpan

How to Wear a Lot of Hats

13 October

Phillip Derosa, Global Director of QA at OneSpan, has never been afraid to fill in the cracks between departmental duties, often coming up with a brand new intermediary position to occupy during times of need.

QA Team
Leadership
Agile / Scrum
Phillip Derosa

Phillip Derosa

Global Director of QA at OneSpan

Powerful Reasons Why Goal Setting Is Important

12 October

Mary Fisher, Software Engineering Manager at DrChrono, shares how goal setting provides the foundation to drive an organization.

Goal Setting
Dev Processes
Deadlines
Productivity
Motivation
Cross-Functional Collaboration
Prioritization
Agile / Scrum
Mary Fisher

Mary Fisher

Software Engineering Manager at DrChrono

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.