Speaker A
Hello and welcome to the geeky way of making engineering teams follow standards collaboratively, a presentation that we have prepared for the Hungarian Software Testing Forum.
Learn how engineering teams can collaboratively follow standards using tools and processes to improve software quality and adoption.
Key Takeaways
- Standards enable engineering teams to work collaboratively and efficiently by agreeing on common rules.
- Measuring adoption of standards through tools helps track progress and identify areas for improvement.
- Historical examples highlight that standardization is critical for safety and coordination, applicable to software.
- A structured proposal and feedback process ensures standards are well-understood and accepted before rollout.
- Self-regulation in software development is vital to maintain quality and avoid external legal or political intervention.
What the video covers
- Presentation by Javier Gómez at the Hungarian Software Testing Forum on collaborative engineering standards.
- Javier Gómez is an engineering manager at Typeform, leading the Engineering Intelligence team.
- The team analyzes software development lifecycle metrics to provide insights on service-level objectives, availability, and incident root cause analysis.
- Standards are defined as agreements between engineers to comply with rules for better collaboration and quality.
- Historical example of time zone standardization in 1883 demonstrates the importance of standards in preventing accidents.
- Software standards include testing frameworks, coverage levels, static analysis, and team delivery processes like Scrum.
- Typeform developed a Standard Adoption Tool to measure and visualize the adoption of standards organization-wide.
- A formal proposal process is used to draft, gather feedback, and approve standards before implementation.
- Teams plan and report on the adoption progress regularly, ensuring continuous improvement.
- Self-regulation in software engineering is encouraged to maintain quality before external regulations intervene.
Chapters
- 00:00Introduction and Presenter Background
- 01:07Engineering Intelligence Team and Metrics Overview
- 02:15Defining What a Standard Is
- 04:53Historical Example: Time Zone Standardization
- 07:31Importance of Standards in Software Engineering
- 09:37Self-Organization and Standard Adoption Tool
- 12:53Standard Proposal Process and Feedback
- 16:58Planning, Reporting, and Success Stories
Full Transcript — Download SRT & Markdown
Speaker A
professional i've always enjoyed the creative and data-driven uh way of looking at technology and through my blogs and talks i hope to inspire many of you iit professionals out there to bring value to your organization in new diverse and ingenious ways
Speaker A
Hi there, I'm Andre, and I'm saying hi from Barcelona. About myself as a professional, I've always enjoyed the creative and data-driven way of looking at technology, and through my blogs and talks, I hope to inspire many of you IT professionals out there to bring value to your organization in new, diverse, and ingenious ways.
Speaker A
in spain and i'm engineering manager at typeform of the engineering intelligence team where we do something like what you would imagine that the hawk eye camera does in the tennis court like analyzing where the ball goes and then providing
Speaker A
In my free time, I enjoy cooking and gastronomical experiences. I include craft beer also in this passion, and currently, I'm studying a master of artificial intelligence.
Speaker A
like measuring server level indicators against service level objectives we have availability metrics performance and we also provide four key metrics for the team and and incident root cause analysis this is the kind of thing that we do at form
Speaker A
And this is me, Javier Gomez. I'm a software engineer, and I live in Tarragona, which is also in Spain. I'm engineering manager at Typeform of the Engineering Intelligence team, where we do something like what you would imagine that the Hawk-Eye camera does on the tennis court, like analyzing where the ball goes and then providing insights out of it.
Speaker A
and this is for example choosing a specific testing framework or deciding on a specific level of coverage before you merge a commit or adding some sort of static analysis linting code or some way of managing the the progress
Speaker A
Like in this image, yeah, this is what we do. We analyze all the parts of the software development life cycle. We obtain metrics, and we provide insights out of it. Like, in our catalog, we have solutions like measuring service-level indicators against service-level objectives. We have availability metrics, performance, and we also provide four key metrics for the team and incident root cause analysis.
Speaker A
engineers to comply with defined rules and you might be wondering and why standards matters yeah well they matter and i'll tell you why with this image of a train so in 1883 it was decided to standardize the the time zones
Speaker A
This is the kind of thing that we do at Typeform.
Speaker A
you know highest point of the sun it's 12 o'clock in this station but then you go with the train to the next station and you need to resync your clock depending on on some position so there was different powers on every station
Speaker A
And let me take you to the beginning of the presentation now. What is a standard? We are talking about standards, but what is a standard? So, a standard is anything that engineers agree on between them in order to follow and to work together.
Speaker A
they collide so that's why they standardized the time as a whole between the u.s and the u.s east and west coast so standardized is important because it saves life and you may say well we do software not not trains we barely
Speaker A
And this is, for example, choosing a specific testing framework or deciding on a specific level of coverage before you merge a commit or adding some sort of static analysis, linting code, or some way of managing the progress and the delivery of the team, like Scrum, or using a specific version of a library. These are examples of standards, but as you see, it can be almost anything.
Speaker A
auto regulate our ourselves before others come to the show like uh politicians or whoever need to come so it's better that we self-organize and and create these standards of quality to prevent obviously clean people but in general to
Speaker A
So, we say a standard is an agreement between engineers to comply with defined rules.
Speaker A
and then we have created what we call the standard option tool that is a way to measure this standard the the level of adoption in the whole organization let me show you a little bit the process so at the very beginning
Speaker A
And you might be wondering, why do standards matter? Yeah, well, they matter, and I'll tell you why with this image of a train. So, in 1883, it was decided to standardize the time zones in the U.S. railroad. This is why we have time zones today, and we can deal with time worldwide.
Speaker A
of deciding if this standard is a goal or a no-go maybe it's not the right moment right now to implement this standard so once it's a goal we define a metrics to measure the adoption and we provide some visualizations of
Speaker A
But in those days, there were no time zones, and the time of every train station was based on the highest point of the sun.
Speaker A
and they they have to report on a weekly by weekly basis on the progress of it let me tell you an example of a standard so i i remember some time ago travis continuous integration changes their policies without any
Speaker A
You know, highest point of the sun, it's 12 o'clock in this station, but then you go with the train to the next station, and you need to resync your clock depending on some position. So, there were different powers on every station.
Speaker A
self-hosted actions could replace travis ci and and there was a standard proposal created but you might wonder in an organization with more than 100 engineers how do you and more than 350 representatives how do you propose such a change you know everyone needs to go
Speaker A
And this resulted in a problem. There were even accidents with people dying because, despite that trains were traveling at the right time according to them, they were traveling in different hours in different directions, and then they collided.
Speaker A
standards and proposal board with the proposal that goes through many stages initially it is drafted and then it starts welcoming feedback of the whole engineering department when there is enough feedback and it was implemented the proposal is moved to
Speaker A
So, that's why they standardized the time as a whole between the U.S. and the U.S. east and west coast.
Speaker A
dropped and reconsidered for a future moment in time to help engineers write strong proposals that will go through we offer a template that aims to make things simple it has different sections the first one is about understanding the
Speaker A
So, standardization is important because it saves lives.
Speaker A
order for the proposal to be fully delivered and the fourth and the last is about providing the details about the automatic tracker of adoption and how we will be checking for the adoption of the standard with the tool that we we provide
Speaker A
And you may say, well, we do software, not trains. We barely are going to kill someone.
Speaker A
case for the implied changes and then you also get the conversation going if you see a write the right data or the right charts helping you with the proposal so to track the progress of adopting a standard we have built the
Speaker A
Okay, yeah, but software today is everywhere, no?
Speaker A
views that we we have for it it empowers anybody just to filter by team by date etc and to understand the adoption percentage in the organization this particular trend you are seeing right now on the screen is the average adoption of all the
Speaker A
And I remember in 2018, an autonomous vehicle killed a cyclist. Software will soon have more legal implications, and I remember Uncle Bob Martin said the best is that we, the software experts, autoregulate ourselves before others come to the show, like politicians or whoever needs to come.
Speaker A
standards that will become mandatory in the next quarter to make it easier for everybody to understand uh in red we also display how the standards will affect the overall adoption if it will be today this empowers teams to plan ahead the
Speaker A
So, it's better that we self-organize and create these standards of quality to prevent obviously clean people, but in general, to work better together.
Speaker A
migrated in septembers were around 95 of the adoption and we are ready to decommission travis right now in this visualization we can see how the rest of the standards are performing uh as you can notice some of the trends
Speaker A
And this is why we want to show you we have created two key artifacts for dealing with standards. Our first one is the Standards and Proposal Board, where everyone at Typeform can create a standard. So, you have an idea, you propose it here.
Speaker A
enable things like for example a cookie cutter or repository templates that already have all the standards in place for you when you start with a fresh repository and to make everybody aware about how to arrive at 100 it's more than critical to
Speaker A
And then we have created what we call the Standard Adoption Tool, which is a way to measure this standard, the level of adoption in the whole organization.
Speaker A
for this we have created a concept of a badge um that is inspired from scouts that you receive badges now for doing a good thing or if you have a certain skill though so we give these badges to to the different repository depending
Speaker A
Let me show you a little bit of the process. So, at the very beginning, any engineer at the company can propose a standard, and then the next stage is a discussion. You obtain feedback, and you improve the standard based on the suggestions of your colleagues.
Speaker A
report stories in order to help engineers understand the particularities behind the standards applied for each one of the repositories in a more friendly format we generate all of that information automatically so we've built an internal tool in typescript that helps us with
Speaker A
And then there is a process of deciding if this standard is a go or a no-go. Maybe it's not the right moment right now to implement this standard.
Speaker A
present in the repository for every evaluation we give different levels of adoption like these levels help us calculate the adoption percentage for that particular repository in this case it's pretty simple it is still have a travis file uh
Speaker A
So, once it's a go, we define metrics to measure the adoption, and we provide some visualizations of who and when has adopted what. So, we are more or less measuring the change, right?
Speaker A
and a one hundred percent we also choose to skip for example a repository um for this evaluation like a travis configuration repository because we know it's strictly related to travis and we will fully uh delete it when we fully migrate away
Speaker A
And then it's time for the teams to plan and put some goals into adopting those standards in a certain amount of time, and they have to report on a weekly or biweekly basis on the progress of it.
Speaker A
nice dashboard you've just seen we need to generate data frequently you know at least on a daily basis so we use airflow to execute the data pipeline that runs the code that we just shown that is extracting all of this data and
Speaker A
Let me tell you an example of a standard. So, I remember some time ago, Travis Continuous Integration changed their policies without any notice, so that screwed us up. We, out of a sudden, started having long queues in our agents. Teams were blocking each other, waiting for their builds to finish.
Speaker A
also thinks hey how are we going to measure the adoption of uh of that standard we can say that also product and platform engineering are proactively planning and working on adopting standards together thanks to this tool and we have now
Speaker A
And so, we started exploring alternatives, and we found out that the self-hosted actions could replace Travis CI, and there was a standard proposal created.
Speaker A
noticed like inevitably that the keeping old code bases up to standard was a lot of work we concluded that through this process the teams became more aware about the deep technical debt that they had accumulated over time and this led to discussions about should
Speaker A
But you might wonder, in an organization with more than 100 engineers and more than 350 representatives, how do you propose such a change? You know, everyone needs to go change their pipelines.
Speaker A
conversation we also can say that we are able to migrate our ccd provider from travis ci to github action in a couple of quarters we didn't need to schedule a special migration operation or the typical constant reminder for platform teams no
Speaker A
And, well, spoiler alert, the answer is with the Standard Proposal Dashboard and the Standard Adoption Tool, and we are going to explain to you how, a history of success with this.
Speaker A
level of adoption and also when the teams were asked to report on the progress on a weekly basis then we saw that the level of adoption started to grow and increasing the whole organization with this solution we are also able to
Speaker A
Well, it all starts here, actually, in the Standards and Proposal Board with the proposal that goes through many stages. Initially, it is drafted, and then it starts welcoming feedback from the whole engineering department.
Speaker A
and go where the most problems are and try to help that team there's a lot to speak about standards and we'd love to do that but uh we know uh sadly there is uh not enough time so we wanted to mention
Speaker A
When there is enough feedback and it was implemented, the proposal is moved to final, waiting for an approval from the decision makers. These are usually directors and some senior engineers, subject matter experts in that particular topic.
Speaker A
there in the audience to think about maybe you can answer them via the q a section or via chat what would you do differently to improve the adoption of standards in your company and what do you need to make a tool like
Speaker A
Finally, a proposal can then move forward, meaning it can be implemented or can be dropped and reconsidered for a future moment in time.
Speaker A
this session today and we'd like to ask you for your feedback so we can improve for ourselves and also the presentation for the next time so scan the qr code and answer the fun video ask we have prepared for you
Speaker A
To help engineers write strong proposals that will go through, we offer a template that aims to make things simple. It has different sections. The first one is about understanding the problem in depth.
Topics:engineering standardssoftware qualitystandard adoptionsoftware metricsengineering collaborationsoftware testingTypeformsoftware lifecycleself-regulationstandard proposal process
