DORA metrics are a compass for engineering teams striving to optimise their development and operations processes.
Consistently tracking these metrics can lead to significant and lasting improvements in your software delivery processes and overall business performance.
Below is a detailed guide on how Typo uses DORA to improve DevOps performance and boost efficiency:
In 2015, The DORA (DevOps Research and Assessment) team was founded by Gene Kim, Jez Humble and Nicole Forsgren to evaluate and improve software development practices. The aim was to improve the understanding of how organisations can deliver software faster, more reliable and of higher quality.
They developed DORA metrics that provide insights into the performance of DevOps practices and help organisations improve their software development and delivery processes. These metrics help in finding answers to these two questions:
DORA metrics helps in assessing software delivery performance based on four key (or accelerate) metrics:
Deployment Frequency measures the number of times that code is deployed into production. It helps in understanding team’s throughput and quantifying how much value is delivered to customers.
When organizations achieve a high Deployment Frequency, they can enjoy rapid releases without compromising the software’s robustness. This can be a powerful driver of agility and efficiency, making it an essential component for software development teams.
One deployment per week is standard. However, it also depends on the type of product.
Lead Time for Changes measures the time it takes for code changes to move from inception to deployment. The measurement of this metric offers valuable insights into the effectiveness of development processes, deployment pipelines, and release strategies.
By analysing the Lead Time for Changes, development teams can identify bottlenecks in the delivery pipeline and streamline their workflows to improve software delivery’s overall speed and efficiency. Shorter lead time states that the DevOps team is more efficient in deploying code.
Change Failure Rate gauges the percentage of changes that require hot fixes or other remediation after production. It reflects the stability and reliability of the entire software development and deployment lifecycle.
By tracking CFR, teams can identify bottlenecks, flaws, or vulnerabilities in their processes, tools, or infrastructure that can negatively impact the quality, speed, and cost of software delivery.
0% — 15% CFR is considered to be a good indicator of your code quality.
Mean Time to Recovery measures how quickly a team can bounce back from incidents or failures. It concentrates on determining the efficiency and effectiveness of an organisation’s incident response and resolution procedures.
A lower mean time to recovery is synonymous with a resilient system capable of handling challenges effectively.
The response time should be as short as possible. 24 hours is considered to be a good rule of thumb.
Reliability is a fifth metric that was added by the DORA team in 2021. It measures modern operational practices and doesn’t have standard quantifiable targets for performance levels.
Reliability comprises several metrics used to assess operational performance that includes availability, latency, performance and scalability that measures user-facing behaviour, software SLAs, performance targets, and error budgets.
Typo is an effective software engineering intelligence platform that offers SDLC visibility, developer insights, and workflow automation to build better programs faster. It offers comprehensive insights into the deployment process through key DORA metrics such as change failure rate, time to build, and deployment frequency.
Below is a detailed view of how Typo uses DORA to boost dev efficiency and team performance:
Typo’s DORA metrics dashboard has a user-friendly interface and robust features tailored for DevOps excellence. This helps in identifying bottlenecks, improves collaboration between teams, optimises delivery speed and effectively communicates team’s success.
DORA metrics dashboard pulls in data from all the sources and presents in a visualised and detailed way to engineering leaders and development team.
DORA metrics helps in many ways:
Firstly, define clear and measurable objectives. Consider KPIs that align with your organisational goals. Whether it’s improving deployment speed, reducing failure rates, or enhancing overall efficiency, having a well-defined set of objectives will help guide your implementation of the dashboard.
Gain a deeper understanding of DORA metrics by exploring the nuances of Deployment Frequency, Lead Time, Change Failure Rate, and MTTR. Then, connect each of these metrics with your organisation’s DevOps goals to have a comprehensive understanding of how they contribute towards improving overall performance and efficiency.
Follow specific guidelines to properly configure your dashboard. Customise the widgets to accurately represent important metrics and personalise the layout to create a clear and intuitive visualisation of your data. This ensures that your team can easily interpret the insights provided by the dashboard and take appropriate actions.
To ensure the accuracy and reliability of your DORA Metrics, establish strong data collection mechanisms. Configure your dashboard to collect real-time data from relevant sources, so that the metrics reflect the current state of your DevOps processes.
Integrate automation tools to optimise the performance of your DORA Metrics Dashboard.
By utilising automation for data collection, analysis, and reporting processes, you can streamline routine tasks. This will free up your team’s time and allow them to focus on making strategic decisions and improvements.
To get the most out of your well-configured DORA Metrics Dashboard, use the insights gained to identify bottlenecks, streamline processes, and improve overall DevOps efficiency. Analyse the dashboard data regularly to drive continuous improvement initiatives and make informed decisions that will positively impact your software development lifecycle.
Typo’s dashboard provides clear and intuitive visualisations of the four key DORA metrics:
It tracks how often new code is deployed to production, highlighting the team’s productivity.
By integrating with your CI/CD tool, Typo calculates Deployment Frequency by counting the number of unique production deployments within the selected time range. The workflows and repositories that align with production can be configured by you.
It measures the time it takes from code being committed to it being deployed in production, indicating the efficiency of the development pipeline.
In the context of Typo it is the average time all pull requests have spent in the “Coding”, “Pickup”, “Review” and “Merge” stages of the pipeline. Typo considers all the merged Pull Requests for the main/master/production branch for the selected time range and calculates the average time spent by each Pull Request in every stage of the pipeline. No open/draft Pull Requests are considered in this calculation.
It shows the percentage of deployments causing a failure in production, reflecting the quality and stability of releases.
There are multiple ways this metric can be configured:
To calculate the final percentage, the total number of failures are divided by the total number of deployments (this can be picked either from the Deployment PRs or from the CI/CD tool deployments).
It measures the time taken to recover from a failure, showing the team’s ability to respond to and fix issues.
The way a team tracks production failure (CFR) defines how MTTR is calculated for that team. If a team considers a production failure as :
DORA metrics deliver crucial insights into team performance. Monitoring Change Failure Rate and Mean Time to Recovery helps leaders ensure their teams are building resilient services with minimal downtime. Similarly, keeping an eye on Deployment Frequency and Lead Time for Changes assures engineering leaders that the team is maintaining a swift pace.
Together, these metrics offer a clear picture of how well the team balances speed and quality in their workflows.
One of the ways organizations are implementing is through a continuous feedback process. While it may seem a straightforward process, it is not. Every developer takes feedback in different ways. Hence, it is important to engineer the feedback the right way.
Below are a few ways why continuous feedback is beneficial for both developers and engineering leaders:
Keeps everyone on the same page: Feedback enables individuals to be on the same page. No matter what type of tasks they are working on. It allows them to understand their strengths and improve their blind spots. Hence, provide high-quality work.
Facilitates improvement: Feedback enables developers the areas they need to improve and the opportunities they can grab according to their strengths. With the right context and motivation, it can encourage software developers to work on their personal and professional growth.
Nurtures healthy relationships: Feedback fosters open and honest communication. It lets developers be comfortable in sharing ideas and seeking support without any judgements even when they aren’t performing well.
Enhances user satisfaction: Feedback helps developers to enhance their quality of work. This can have a direct impact on user satisfaction which further positively affects the organization.
Strength performance management: Feedback enables you to set clear expectations, track progress, and provide ongoing support and guidance to developers. This further strengthens their performance and streamlines their workflow.
There are a lot of things to consider when giving effective and honest feedback. We’ve divided the process into three sections. Do check it out below:
Plan in advance how will you start the conversation, what is worth mentioning, and what is not. For example, if it is related to pull requests, can start by discussing their past performance related to the same. Further, you can talk about how well are they performing, whether they are delivering the work on time, rating their performance and action plan, and if there are any challenges they are facing. Make sure to relate it to the bigger picture.
When framed appropriately and constructively, it helps in focusing on improvement rather than criticism. It also enables developers to take feedback the right way and help them grow and succeed.
Observe and note down everything related to the developers. Track their performance continuously. Jot down whatever noticed even if it is not worth mentioning during the feedback session. It allows you to share feedback more accurately and comprehensively. It also helps you to identify the trends and patterns in developer performance and lets them know that the feedback isn’t based on isolated incidents but rather the consistent observation.
For example, XYZ is a software developer at ABC organization. The engineering leader observed XYZ for three months before delivering effective feedback. She told him:
So, the engineering leader was able to discuss effectively his strengths and areas of improvement.
Before offering feedback to software development teams, make sure you are well aware of the differences between constructive feedback and criticism. Constructive feedback encourages developers to enhance their personal and professional development. On the other hand, criticism enables developers to be defensive and hinder their progress.
Constructive feedback allows you to focus on the behavior and outcome of the developers and help them by providing actionable insights while criticism focuses on faults and mistakes without providing the right guidance.
For example,
Situation: A developer’s recent code review missed several critical issues.
Feedback: “Your recent code review missed a few critical issues, like the memory leak in the data processing module. Next time, please double-check for potential memory leaks. If you’re unsure how to spot them, let’s review some strategies together.”
Criticism: “Your code reviews are sloppy and miss too many important issues. You need to do a better job.”
Review previous feedback given to developers before the session. Check what was last discussed and make sure to bring it up again. Also, include those that were you tracking during this time and connect them with the previous feedback process. Look for metrics such as pull request activity, work progress, team velocity, work log, check-ins, and more to get in-depth insights about their work. You can also gather peer reviews to get 360-degree feedback and understand better how well individuals are performing.
This makes your feedback balanced and takes into account all aspects of developers’ contributions and challenges.
The feedback shouldn’t be a top-down approach. It must go both ways. You can start by bringing up the discussion that happened in the previous feedback session. Know their opinion and perspective on certain topics and ideas. Make sure that you ask questions to make them realize that you respect their opinions and want to hear what they want to discuss.
Now, share your feedback based on the last discussion, observations, and performance. You can also modify your feedback based on their perspective and reflections. It allows the feedback to be detailed and comprehensive.
When you have shared their areas of improvement, make sure you provide them with clear actionable plans as well. Discuss with them what needs immediate attention and what steps can they take. Set small goals with them as it makes it easier to focus on them and let them know that their goals are important. You must also schedule follow-up meetings with them after they reach every step and understand if they are facing any challenges. You can also provide resources and tools that can help them attain their goals.
Developed by the Center for Creative Leadership, the SBI stands for situation, behavior, and impact framework. It includes:
Example: Last week’s team collaboration on the new feature development.
Example: “You did not participate actively in the brainstorming sessions and missed a few important meetings.”
Example: “This led to a lack of input from your side, and we missed out on potentially valuable ideas. It also caused some delays as we had to reschedule discussions.”
Final words could be: “Please ensure to attend all relevant meetings and actively participate in discussions. Your contributions are important to the team.”
This allows for delivering feedback that is clear, actionable, and respectful. It makes it relevant and directly tied to the situation. Note that, this framework is for both positive and negative feedback.
It is also important to know if any constraints are negatively impacting their performance. It could include tight deadlines or a heavy workload that is hampering their productivity or facing health issues due to which they aren’t able to focus properly. Ask them while you deliver feedback to them. You can further create actionable plans accordingly. This shows developers that you care for them and makes the feedback more personalized and relevant. Besides this, it also allows you to share tangible improvements rather than adding more pressure.
For example: “During the last sprint, there were a few missed deadlines. Is there something outside of work that might be affecting your ability to meet these deadlines? Please let me know if there’s anything we can do to accommodate your situation.”
Before concluding the meeting, ask them if there’s anything they would like to discuss. It could likely be that they have missed out on something or it wasn’t bought up during the session.
Afterwards, summarize what has been discussed. Ask the developers what are their key takeaways from the session and share your perspective as well. You can document the summary to help you and developers in the future feedback meetings. This gives mutual understanding and ensures that both are on the same page.
Keep a record of what was discussed during this session and action plans provided to the developers. You can take a look at them in future feedback meetings or performance evaluations. An example of the structure of summary:
Ensure you give them measurable goals and timelines during the feedback session. Monitor their progress through check-ins, provide ongoing support and guidance, and keep discussing the challenges or roadblocks they are facing. It helps the developers stay on track and feel supported throughout their journey.
Typo is an effective software engineering intelligence platform that can help in improving the feedback process within development teams. Here’s how Typo’s features can be leveraged to enhance feedback sessions:
For more information, visit our website!
Software developers deserve high-quality feedback. It not only helps them identify their blind spots but also polishes their skills. The feedback loop lets developers know where they stand and the recognition they deserve.
Building a high-performing engineering team is crucial for the success of any company, especially in the dynamic and constantly evolving world of technology. Whether you’re a startup on the rise or an established enterprise looking to maintain your competitive edge, having a well-structured engineering team is essential.
This blog will explore the intricacies of building and structuring engineering teams for scale and success. We’ll cover many topics, including talent acquisition, skill development, team management, and more.
Whether you’re a CTO, a team leader, or an entrepreneur looking to build your own engineering team, this blog will equip you with the knowledge and tools to create a high-performing engineering team that can drive innovation and help you achieve your business goals.
Before we dive into the specifics of team structure, it’s vital to understand the dynamics that shape engineering teams. Various factors, including team size, communication channels, leadership style, and cultural fit, influence these dynamics. Each factor plays a significant role in determining how well a team operates.
The size of a team can significantly impact its operation. Smaller teams tend to be more agile and flexible, making it easier for them to make quick decisions and respond to project changes. On the other hand, larger teams can provide more resources, skills, and knowledge, but they may struggle with communication and coordination.
Effective communication is essential for any team’s success. In engineering teams, communication channels play a significant role in ensuring team members can collaborate effectively. Different communication channels, such as email, chat, video conferencing, or face-to-face, can impact the team’s effectiveness.
A team leader’s leadership style can significantly impact the team’s effectiveness. Autocratic leaders tend to make decisions without input from team members, while democratic leaders encourage team members to participate in decision-making. Moreover, transformational leaders inspire and motivate team members to achieve their best.
Cultural fit refers to how well team members align with the team’s values, norms, and beliefs. A team that has members with similar values and beliefs is more likely to work well together and be more productive. In contrast, a team with members with conflicting values and beliefs may struggle to work effectively.
Scaling engineering teams can present challenges, and planning and strategizing thoughtfully is crucial to ensure that the team remains effective. Understanding the dynamics that shape engineering teams can help teams overcome these challenges and work together effectively.
An engineering team must be diverse and collaborative. Each team member should specialize in a particular area but also be able to comprehend and collaborate with others in building a product.
A few of them include:
The software development team lead plays a crucial role in guiding and coordinating the efforts of the software development team. They could have under 10 to hundreds of team members under their lead.
Software developers write the code, their job is purely technical and they build the product. Most of them are individual contributors i.e. they have no management or HR responsibilities.
Product managers define the product vision, gather and prioritize requirements, and deal with collaboration with engineering teams.
Designers create user-friendly interfaces, develop prototypes to visualize concepts and iterate on feedback-based designs.
Once the dynamics of engineering teams are understood, organizations can apply key principles to build and structure teams for scale. From defining goals and establishing role clarity to fostering a culture of collaboration and innovation, these principles serve as a foundation for effective team building.
There is no one-size-fits-all approach to structuring engineering teams. Different structures may be more suitable depending on the organization’s size, industry, and goals. Organizations can identify the structure that best aligns with their unique needs and objectives by exploring various approaches.
The top two approaches are:
When teams are formed based on the project for a defined period. It is a traditional way where engineers and designers are selected from their respective departments and tasked with project-related work.
It may seem logical, but it poses challenges. Project-based teams can prioritize short-term objectives and collaborating with unfamiliar team members can lead to communication gaps, particularly between developers and other project stakeholders.
When teams are aligned around specific products or features to promote ownership and accountability. Since this team structure is centered around the product, it is a long-term project, and team members are bound to work together more efficiently.
As the product gains traction and attracts users, the team needs to adapt to a changing environment i.e. restructuring and hiring specialists.
Other approaches include:
In engineering organizations, there is a tendency to rely heavily on one person for all responsibilities rather than distributing them among team members. It not only leads to bottlenecks and inefficiencies but also, slows down progress and the inability to deliver quality products.
The two most common communication issues while structuring and building engineering teams are – Alignment and context-switching between engineering teams. This increases the miscommunication among team members and leads to duplication of work, neglected responsibilities, and coverage gaps.
When engineering leaders micromanage developers, it can hinder productivity, innovation, and overall team effectiveness. Hence, having a structure that fosters optimization, ownership, and effectiveness is important for building an effective team.
Scaling an engineering team requires careful planning and execution. Here are the best practices to build a team that scales well:
Building and structuring engineering teams for scale is a multifaceted endeavor that requires careful planning, execution, and adaptation.
But this doesn’t end here! Measuring a team’s performance is equally important to build an effective team. This is where Typo comes in!
It is an intelligent engineering management platform used for gaining visibility, removing blockers, and maximizing developer effectiveness. It gives a comparative view of each team’s performance across velocity, quality, and throughput.
For more information, check out our website!
Agile project management relies on iterative development cycles to deliver value efficiently. Central to this methodology is the iteration burndown chart, a visual representation of work progress over time. In this blog, we’ll explore leveraging and enhancing the iteration burndown chart to optimize Agile project outcomes and team collaboration.
An iteration burndown chart is a graphical representation of the total work remaining over time in an Agile iteration, helping teams visualize progress toward completing their planned work.
It typically includes an ideal line representing the planned progress, an actual line indicating the real progress, and axes to represent time and work remaining.
The chart enables teams to monitor their velocity, identify potential bottlenecks, and make data-driven decisions to ensure successful iteration completion.
Understanding the advantages of iteration burndown charts is key to appreciating their value in Agile project management. From enhanced visibility to improved decision-making, these charts offer numerous benefits that can positively impact project outcomes.
Crafting an effective iteration burndown chart requires a thorough and step-by-step approach. Here are some detailed guidelines to help you create a well-designed burndown chart that accurately reflects progress and facilitates efficient project management:
By following these detailed guidelines, you’ll be able to create an accurate and effective iteration burndown chart that can help you and your team monitor your project’s progress and manage it more efficiently.
While creating a burndown chart is a crucial first step, maximizing its effectiveness requires ongoing attention and refinement. These tips will help you harness the full potential of your iteration burndown chart, empowering your development teams to achieve greater success in Agile projects.
Continuous improvement lies at the heart of Agile methodology, and your iteration burndown chart is no exception. By incorporating feedback, analyzing historical data, and experimenting with different approaches, you can refine your chart to better meet your team’s and stakeholders’ needs.
A burndown chart is great for evaluating the ratio of work remaining and the time it takes to complete the work. However, relying solely on a burndown chart is not the right way due to certain limitations.
Although creating a burndown chart in Excel is easy, entering data manually requires more time and effort. This makes the work repetitive and tiresome after a certain point.
The Burndown chart helps to track the progress of completing tasks or user stories over time within a sprint or iteration. But, it doesn’t provide insights about the specific types of issues or tasks being worked on. It includes shipping new features, determining technical debt, and so on.
A burndown chart doesn’t differentiate between an easy and difficult task. It considers all of them equal, regardless of their size, complexity, or effort required to complete it. Hence, leading to ineffective outlines of project progress. This further potentially masks critical issues and hinders project management efforts.
The burndown chart primarily focuses on tracking remaining work throughout a sprint, but it doesn’t directly indicate the predictability of completing that work within the sprint timeframe. It lacks insight into factors like team velocity fluctuations or scope changes, which are crucial for assessing sprint predictability accurately.
Typo’s sprint analysis is an essential tool for any team using an agile development methodology. It allows agile teams to track and analyze overall progress throughout a sprint timeline. It helps to gain visual insights into how much work has been completed, how much work is still in progress, and how much time is left in the sprint. This information can help to identify any potential problems early on and take corrective action.
Our sprint analysis feature uses data from Git and issue management tools to provide insights into how software development teams are working. They can see how long tasks are taking, how often they’re being blocked, and where bottlenecks are occurring.
It is easy to use and can be integrated with existing Git and Jira/Linear/Clickup workflows.
The iteration burndown chart is a vital tool in Agile project management. It offers agile and scrum teams a clear, concise way to track progress and make data-driven decisions.
However, one shouldn’t rely solely on the burndown charts. Moreover, there are various advanced sprint analysis tools such as Typo in the market that allow teams to track and gain visual insights into the overall progress of the work.
Jira is a widely used project management tool that enables teams to work together efficiently and achieve outstanding outcomes. The Jira dashboard is a vital component of this tool, offering teams valuable insights, metrics, and project visibility. In this journey, we will explore the potential of Jira dashboards and learn how to leverage their full capabilities.
A Jira dashboard serves as the nerve center of project activity, offering a consolidated view of tasks, progress, and key metrics. It gives stakeholders a centralized location to monitor project health, track progress, and make informed decisions.
These modular components provide specific information and functionality, such as task lists, burndown charts, and activity streams. There are several gadgets built into Jira such as filter results gadget, issue statistics gadget, and road map gadget. However, additional gadgets can also be downloaded from the Atlassian Marketplace. Some of them are the pivot gadget and gauge gadget.
Jira dashboards host various reports, including velocity charts, sprint summaries, and issue statistics, offering valuable insights into team performance, and project trends.
Jira dashboards are used for several reasons:
The default dashboard is also known as the system dashboard. It is the screen Jira users see the first time they log in. It includes gadgets from Jira’s pre-installed selection and is limited to only one dashboard page.
Creating custom dashboards requires careful planning and consideration of project objectives and team requirements. Let’s explore the step-by-step process of crafting a bespoke dashboard:
Log in to your Jira account. Go to the dashboard and click ‘Create Dashboard’.
Start by defining the objectives and goals of your dashboard page. Determine what information is crucial for your team to track and monitor, and tailor your dashboard accordingly.
Choose gadgets and reports that align with your project’s needs and objectives. When curating your dashboard content, consider factors such as team workflow, project complexity, and stakeholder requirements.
Choose your preferred dashboard layout and configuration to ensure optimal visibility and usability for all stakeholders. Arrange gadgets and reports logically and intuitively to facilitate easy navigation and information access.
Embrace an iterative dashboard refinement approach. Solicit user and stakeholder feedback to improve its effectiveness and usability continuously. Regularly assess and update your dashboard to reflect evolving project needs and priorities.
Don’t forget to share the Jira dashboard with the team. This ensures transparency and fosters a collaborative culture. By granting appropriate permissions, they can view and interact with the dashboard and get real-time updates.
A personal dashboard is tailored to individual needs and offers various advantages in streamlining workflow management and improving productivity. It provides a centralized platform for organizing and visualizing user’s tasks, different projects, issues, etc.
This dashboard gives real-time updates on whether the team is on pace to meet a sprint goal. It offers a glimpse of how much work is left in the queue and how long your team will take to complete it. Moreover, the sprint burndown dashboard allows you to jump on any issue when the remaining workload is pacing slower than the delivery date.
The workload dashboard, also known as the monitor resource dashboard tracks the amount of work assigned to each team member and adjusts their workload accordingly. It helps identify workload patterns and plan resource allocation.
The issue tracking dashboard allows users to quickly identify and prioritize the most important issues. It focuses on providing visibility into the status and progress of issues or tickets within a project.
To maximize the impact of your Jira dashboard, consider the following best practices:
Share your dashboard with relevant stakeholders to promote transparency and collaboration. Encourage team members to actively engage with the dashboard and provide feedback to drive continuous improvement.
Integrating your Jira dashboard with other tools and systems is the best way to automate data capture and reporting processes. Leverage integration capabilities to streamline workflow management and enhance productivity.
Empower project teams and leaders to make informed decisions by providing access to actionable insights and performance metrics through the dashboard. Encourage data-driven discussions and decision-making to drive project success.
Take your Jira dashboard customization to the next level with advanced techniques and strategies:
Implement filters and contextualization techniques to personalize the dashboard experience for individual users or specific project phases. Allow users to tailor the dashboard view based on their preferences and requirements.
Utilize dynamic updating capabilities to ensure that your dashboard reflects real-time changes and updates in project data. Implement automated refresh intervals and notifications to keep stakeholders informed and engaged.
Explore the possibilities of custom gadgets and extensions to extend the functionality of your Jira dashboard. Develop custom gadgets or integrate third-party extensions to address unique project requirements and enhance user experience.
Typo’s sprint analysis feature can be seamlessly integrated with the Jira dashboard. It allows to track and analyze the team’s progress throughout a sprint and provides valuable insights into work progress, work breakup, team velocity, developer workload, and issue cycle time.
The benefits of Sprint analysis feature are:
A well-designed Jira dashboard is a catalyst for project excellence, providing teams with the insights and visibility they need to succeed. By understanding its components, crafting a tailored dashboard, and maximizing its impact, you can unlock Jira dashboards’ full potential and drive your projects toward success.
Furthermore, while Jira dashboards offer extensive functionalities, it’s essential to explore alternative tools that may simplify the process and enhance user experience. Typo is one such tool that streamlines project management by offering intuitive dashboard creation, seamless integration, and a user-friendly interface. With Typo, teams can effortlessly visualize project data, track progress, and collaborate effectively, ultimately leading to improved productivity and project outcomes. Explore Typo today and revolutionize your project management experience.
Scrum has become one of the most popular project management frameworks, but like any methodology, it’s not without its challenges. Scrum anti-patterns are common obstacles that teams may face, leading to decreased productivity, low morale, and project failure. Let’s explore the most prevalent Scrum anti patterns and provide practical solutions to overcome them.
A lack of a clear Definition of Done (DoD) can cause teams to struggle to deliver shippable increments at the end of each sprint. It can be due to a lack of communication and transparency. This ambiguity leads to rework and dissatisfaction among stakeholders.
Collaboration is key to establishing a robust DoD. Scrum team members should work together to define clear criteria for completing each user story. These criteria should encompass all necessary steps, from development to testing and acceptance. The DoD should be regularly reviewed and refined to adapt to evolving project needs and ensure stakeholder satisfaction.
One of the common anti patterns is overcommitment during sprint planning meetings. It sets unrealistic expectations, leading to compromised quality and missed deadlines.
Base sprint commitments on past performance and team capacity rather than wishful thinking. Focus on realistic sprint goal setting to ensure the team can deliver commitments consistently. Emphasize the importance of transparency and communication in setting and adjusting sprint goals.
Micromanagement stifles team autonomy and creativity, leading to disengagement, lack of trust and reduced productivity.
Scrum Masters should adopt a servant-leadership approach, empowering teams to self-organize and make decisions autonomously. They should foster a culture of trust and collaboration where team members feel comfortable taking ownership of their work. They should provide support and guidance when needed, but avoid dictating tasks or solutions.
Disengaged Product Owners fail to provide clear direction and effectively prioritize the product backlog, leading to confusion and inefficiency.
Encourage regular communication and collaboration between the Product Owner and the development team. Ensure that the Product Owner is actively involved in sprint planning, backlog refinement, and sprint reviews. Establish clear channels for feedback and decision-making to ensure alignment with project goals and stakeholder expectations.
Failing to embrace a mindset of continuous improvement and adaptation leads to stagnation and inefficiency.
Prioritize retrospectives and experimentation to identify areas for improvement. Encourage a culture of learning and innovation where team members feel empowered to suggest and implement changes. Emphasize the importance of feedback loops and iterative development to drive continuous improvement and adaptation.
Allowing the project scope to expand unchecked during the sprint leads to incomplete work and missed deadlines.
Define a clear product vision and prioritize features based on value and feasibility. Review and refine the product backlog regularly to ensure that it reflects the most valuable and achievable items. Encourage stakeholder collaboration and feedback to validate assumptions and manage expectations.
Siloed teams hinder communication and collaboration, leading to bottlenecks and inefficiencies.
Foster a collaboration and knowledge-sharing culture across teams and disciplines. Encourage cross-functional teams to work together towards common goals. Implement practices such as pair programming, code reviews, and knowledge-sharing sessions to facilitate collaboration and break down silos.
Rushing through sprint retrospective and review meetings results in missed opportunities for feedback and improvement.
Allocate sufficient time for thorough discussion and reflection during sprint review and retrospective meetings. Encourage open and honest communication and ensure that all development team members have a chance to share their insights and observations. Based on feedback and retrospective findings, prioritize action items for continuous improvement.
Product Owners making unrealistic commitments disrupt the team’s focus and cause delays.
Establish a clear process for managing changes to the product backlog. Encourage collaboration between the Product Owner and the development team to negotiate realistic commitments and minimize disruptions during the sprint. Prioritize backlog items based on value and effort to ensure the team consistently delivers on its commitments.
Limited involvement or feedback from stakeholders leads to misunderstandings and dissatisfaction with the final product.
Engage stakeholders early and often throughout the project lifecycle. Solicit feedback and involve stakeholders in key decision-making processes. Communicate project progress regularly and solicit input to ensure alignment with stakeholder expectations and requirements.
Neglecting to address technical debt results in decreased code quality, increased bugs, and slower development velocity over time.
Allocate time during each sprint for addressing technical debt alongside new feature development. Encourage collaboration between developers and stakeholders to prioritize and tackle technical debt incrementally. Invest in automated testing and refactoring to maintain code quality and reduce technical debt accumulation.
Failing to implement continuous integration and deployment practices leads to integration issues, longer release cycles, and reduced agility.
Establish automated CI/CD pipelines to ensure that code changes are integrated and deployed frequently and reliably. Invest in infrastructure and tools that support automated testing and deployment. Encourage a culture of automation and DevOps practices to streamline the development and delivery process.
Daily scrum meeting is usually used synonymously with daily status meetings. This loses its focus on collaboration and decision-making. Sometimes, team members don’t find any value in these meetings leading to disengagement and decreased motivation.
In daily scrums, the focus should only be on talking to each other about what’s the most important work to get done that day and how to do it. Encourage team members to collaborate to tackle problems and achieve sprint goals. Moreover, keep the daily scrums short and timeboxed, typically to 15 minutes.
Successfully implementing Scrum requires more than just following the framework—it demands a keen understanding of potential pitfalls and proactive strategies to overcome them. By addressing common Scrum anti patterns, teams can cultivate a culture of collaboration, efficiency, and continuous improvement, leading to better project outcomes and stakeholder satisfaction.
However, without the right tools, identifying and addressing these anti-patterns can be daunting. That’s where Typo comes in. Typo is an intuitive project management platform designed to streamline Agile processes, enhance team communication, and mitigate common Scrum challenges.
With Typo, teams can effortlessly manage their Scrum projects, identify and address anti-patterns in real-time, and achieve greater success in their Agile endeavors.
So why wait? Try Typo today and elevate your Scrum experience to new heights!
Jira software has become the backbone of project management for many teams across various industries. Its flexibility and powerful features make it an invaluable tool for organizing tasks, tracking progress, and collaborating effectively. However, maximizing its potential requires more than just basic knowledge. To truly excel in Jira ticket management, you must implement strategies and best practices that streamline your workflows and enhance productivity.
Jira is a popular project management tool developed by Atlassian, commonly used for issue tracking, bug tracking, and project management. Jira ticket management refers to the process of creating, updating, assigning, prioritizing, and tracking issues within Jira.
One of the major challenges with Jira ticketing platform is that it requires a lot of tedious and manual work. This leads to developer frustration, incomplete ticket updates, and undocumented work.
Setting up Jira software to align with the specific needs of a team or project can be complicated. Configuring workflows, custom fields, and permissions requires careful planning and may involve a learning curve for administrators.
Due to the above-mentioned points, it can lead to software development team work becoming untracked and invisible. Hence, the team lacks data hygiene which further leads top management to make decisions with incomplete information. This can further impact planning accuracy as well.
Below are some essential tips to help you manage your Jira tickets better:
Developers often find it labor-intensive to keep tickets updated. Hence, JIRA provides some automation that eases the work of developers. Although these automations are a bit complex initially, once mastered, they offer significant efficiency gains. Moreover, they can be customized as well.
Here are a few JIRA automation that you can take note of:
This is one of the most commonly used automation that involves ensuring accountability for an issue by automatically assigning it to its creator. It ensures that there is always a designated individual responsible for addressing the matter, streamlining workflow management and accountability within the team.
This automation can be customized to suit various scenarios, such as applying it to epics and stories or refining it with specific conditions tailored to your workflow. For example, when a bug issue is reported, you can set up automation to automatically create tasks aimed at resolving the problem. It not only streamlines the process but also ensures that necessary tasks are promptly initiated, enhancing overall efficiency in issue management.
Implementing this advanced automation involves creating a duplicate of an issue in a different project when it undergoes a specific transition. It also leaves a comment on the original issue to establish a connection between them. It becomes particularly valuable in scenarios where one project is dedicated to managing customer requests, while another project is focused on executing the actual work.
This automation automatically computes and assigns a due date to an issue when it’s moved from the backlog to the ‘In Progress’ status. This streamlines the process of managing task timelines, ensuring that deadlines are promptly established as tasks transition into active development stages.
Establishing clear guidelines for creating tickets ensures consistency across your projects. Include essential details such as a descriptive title, priority level, assignee, and due date. This ensures that everyone understands what needs to be done at a glance, reducing confusion and streamlining the workflow.
Moreover, standardizing ticket creation practices fosters alignment within your team and improves communication. When everyone follows the same format for ticket creation, it becomes easier to track progress, assign tasks, and prioritize work effectively. Consistency also enhances transparency, as stakeholders can quickly grasp the status of each ticket without needing to decipher varying formats.
Tailoring Jira workflows to match your team’s specific processes and requirements is essential for efficient ticket management. Whether you follow Agile, Scrum, Kanban, or a hybrid methodology, configure workflows that accurately reflect your workflow stages and transitions. This customization ensures your team can work seamlessly within Jira, optimizing productivity and collaboration.
Customizing workflows allows you to streamline your team’s unique processes and adapt to changing project needs. For example, you can define distinct stages for task assignment, development, testing, and deployment that reflect your team’s workflow. Custom workflows empower teams to work more efficiently by clarifying task progression and facilitating smoother handoffs between team members.
Not all tasks are created equal in Jira. Use priority fields to categorize tickets based on urgency and importance. This strategic prioritization helps your team focus on high-priority items and prevents critical tasks from slipping through the cracks. By prioritizing effectively, you can ensure that important deadlines are met and resources are allocated efficiently.
Effective prioritization involves considering various factors, such as project deadlines, stakeholder requirements, and resource availability. By assessing the impact and urgency of each task, teams can more effectively allocate their time and resources. Regularly reviewing and updating priorities ensures your team remains agile and responsive to changing project needs.
Leverage tags or custom fields to add context to your tickets. Whether it’s categorizing tasks by feature, department, or milestone, these metadata elements make it easier to filter and search for relevant tickets. By utilizing labels and tags effectively, you can improve organization and streamline ticket management within Jira.
Furthermore, consistent labeling conventions enhance collaboration and communication across teams. When everyone adopts a standardized approach to labeling tickets, it becomes simpler to locate specific tasks and understand their context. Moreover, labels and tags can provide valuable insights for reporting and analytics, enabling teams to track progress and identify trends over time.
Effective communication is the cornerstone of successful project management. Encourage team members to provide detailed updates, ask questions, and collaborate openly within Jira ticket comments. This transparent communication ensures that everyone stays informed and aligned, fostering a collaborative environment conducive to productivity and success.
Clear communication within Jira ticket comments keeps team members informed and facilitates knowledge sharing and problem-solving. Encouraging open dialogue enables team members to provide feedback, offer assistance, and address potential roadblocks promptly. Additionally, documenting discussions within ticket comments provides valuable context for future reference, aiding in project continuity and decision-making.
Identify repetitive tasks or processes and automate them using Jira’s built-in automation features or third-party integrations. This not only saves time but also reduces the likelihood of human error. By automating repetitive tasks, you can free up valuable resources and focus on more strategic initiatives, improving overall efficiency and productivity.
Moreover, automation can standardize workflows and enforce best practices, ensuring project consistency. By defining automated rules and triggers, teams can streamline repetitive processes such as task assignments, status updates, and notifications. This minimizes manual intervention and enables team members to devote their time and energy to tasks that require human judgment and creativity.
Continuously reviewing your Jira setup and workflows is essential to identify areas for improvement. Solicit feedback from team members and stakeholders to understand pain points and make necessary adjustments. By regularly reviewing and refining your Jira configuration, you can optimize processes and adapt to evolving project requirements effectively.
Moreover, regular reviews foster a culture of continuous improvement within your team. By actively seeking feedback and incorporating suggestions for enhancement, you demonstrate a commitment to excellence and encourage team members to engage. Additionally, periodic reviews help identify bottlenecks and inefficiencies, allowing teams to address them proactively and maintain high productivity levels.
Jira seamlessly integrates with a wide range of third-party tools and services, enhancing its capabilities and extending its functionality. Integrating with other tools can streamline your development process and enhance collaboration, whether it’s version control systems, CI/CD pipelines, or communication platforms. Incorporating workflow automation tools into the mix further enhances efficiency by automating repetitive tasks and reducing manual intervention, ultimately accelerating project delivery and reducing errors.
Furthermore, integrating Jira with other tools promotes cross-functional collaboration and data sharing. By connecting disparate systems and centralizing information within Jira, teams can eliminate silos and improve visibility into project progress. Additionally, integrating with complementary tools allows teams to leverage existing investments and build upon established workflows, maximizing efficiency and effectiveness.
Encourage a mindset of continuous improvement within your software teams. Encourage feedback, experimentation, and learning from both successes and failures. By embracing a culture of constant improvement, you can adapt to changing requirements and drive greater efficiency in your Jira ticket management process while also building a robust knowledge base of best practices and lessons learned.
Moreover, fostering a culture of continuous improvement empowers team members to take ownership of their work and seek opportunities for growth and innovation. By encouraging experimentation and learning from failures, teams can cultivate resilience and agility, enabling them to thrive in dynamic environments. Additionally, celebrating successes and acknowledging contributions fosters morale and motivation, creating a positive and supportive work culture.
Better JIRA ticket management helps in improving planning accuracy. Below are a few of the ways how these strategies can further help in better planning:
Improving your Jira ticket management, essential for effective task management, requires thoughtful planning, ongoing refinement, and a commitment to best practices. Implementing these tips and fostering a culture of continuous improvement can optimize your workflows, enhance collaboration, and drive greater project success, benefiting both internal teams and external customers.
If you need further help in optimizing your engineering processes, Typo is here to help you.
Curious to know more? Learn about Typo here!
In Agile project management, it is crucial to get a clear picture of the project’s reality. Hence, one of the best ways is to visualize the progress.
A Burndown chart is a project management chart that shows the remaining work needed to reach project completion over time.
Let’s understand how can you create a burndown chart in Excel:
A Burndown chart visually represents teams’ or projects’ progress over time. It analyzes their pace, reflects progress, and determines if they are on track to complete it on time.
Burndown charts are generally of three types:
The product burndown chart focuses on the big picture and visualizes the entire project. It determines how many product goals the development team has achieved so far and the remaining work.
Sprint burndown charts focus on the ongoing sprints. It indicates progress towards completing the sprint backlog.
This chart focuses on how your team is performing against the work in the epic over time. It helps to track the advancement of major deliverables within a project.
A burndown chart has two axes: X and Y. The horizontal axis represents the time or iteration and the vertical axis displays user story points.
It is the diagonal line sloping downwards that represents the remaining work a team has at a specific point of the project or sprint under ideal conditions.
It is a realistic depiction of the team’s performance that is updated in real-time. It is drawn as the teams progress and complete user stories.
Each point on the work lines displays a measurement of work remaining at a given time.
It is the rightmost point of your burndown chart that represents whether the team has completed a project/sprint on time, behind, or ahead of schedule.
A Burndown chart helps in keeping an eye on teams’ work progress visually. This is not only simple to use but also motivates the team to perform well.
A burndown chart is useful to show the direct comparison between planned work and actual progress over time. This helps in quickly assessing whether the team is on track to meet its goals.
A burndown chart acts as a tool for inspiration. Such types of charts transparently show the progress and work efficiency. Hence, improving the collaboration and cooperation between team members.
A burndown chart must be updated daily. This helps in tracking progress in real-time, identifying problems in early stages hence, assisting in completing the project on time.
Open a new sheet in Excel and create a new table that includes 3 columns.
The first column should include the dates of each sprint, the second column have the ideal burndown i.e. ideal rate at which work will be completed and the last column should have the actual burndown i.e. updating them as story points get completed.
Now, fill in the data accordingly. This includes the dates of your sprints and numbers in the Ideal Burndown column indicating the desired number of tasks remaining after each day throughout the let’s say, 10-day sprint.
As you complete tasks each day, update the spreadsheet to document the number of tasks you can finish under the ‘Actual Burndown’ column.
Now, it’s time to convert the data into a graph. To create a chart, follow these steps: Select the three columns > Click ‘Insert’ on the menu bar > Select the ‘Line chart’ icon, and generate a line graph to visualize the different data points you have in your chart.
Study project scope and divide the projects or sprints into short-term tasks. Ensure to review them and estimate the time required to complete each task based on the project deadline.
The Scrum master must check the chart often and update it daily. It helps to understand the flagging trends, know the pitfalls, and ensure it aligns with the expectations.
Don’t lose sight of the outcome. By focusing on it, software development teams can ensure they are making progress toward their goals and adjust their efforts accordingly to stay on track for successful project completion.
Teams pause the work during weekends or holidays. Excluding weekends provides accuracy by focusing solely on the days when active work is being done hence giving a clearer representation of progress and highlighting the team’s actual productivity levels during working days.
Burndown chart, when accessible to the entire team, fosters collaboration and accountability. It gives them a sense of ownership to discuss points to address challenges and celebrate achievements.
A burndown chart is great for evaluating the ratio of work remaining and the time it takes to complete the work. However, relying solely on a burndown chart is not the right way due to certain limitations.
Although creating a burndown chart in Excel is easy, entering data manually requires more time and effort. This makes the work repetitive and tiresome after a certain point.
There are various tools available in the market that offer collaboration and automation features including Jira, Trello, and Asana.
The Burndown chart helps in tracking the progress of completing tasks or user stories over time within a sprint or iteration. But, it doesn’t provide insights about the specific types of issues or tasks being worked on. It includes shipping new features, determining technical debt, and so on.
A burndown chart doesn’t differentiate between an easy and difficult task. It considers all of them equal, regardless of their size, complexity, or effort required to complete it. Hence, leading to ineffective outlines of project progress. This further potentially masks critical issues and hinders project management efforts.
As a result, the burndown chart is not a reliable metric engineering leaders can solely trust. It is always better to complement it with sprint analysis tools to provide additional insights tailored to agile project management. A few of the reasons are stated below:
Typo’s sprint analysis feature allows engineering leaders to track and analyze their team’s progress throughout a sprint. It uses data from Git and the issue management tool to provide insights into getting insights on how much work has been completed, how much work is still in progress, and how much time is left in the sprint hence, identifying any potential problems early on and taking corrective action.
Martin Fowler once said “Anyone can write a code that a computer can understand. Good programmers write code that humans can understand.”
Clean code is an essential component of software development.
Writing clean code is exactly like a sales pitch. When you use words full of technical jargon, you end up losing your target audience. The same is true with coding as well. Writing clean code enhances the readability, maintainability, and understandability of the software.
Robert C. Martin in his book “Clean Code: A Handbook of Agile Software Craftsmanship“ defined clean code as:
“A code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have laid appropriate attention to details. They have cared.”
Clean code is clear, understandable, and maintainable. It is well-organized, properly documented, and follows standard conventions. The purpose behind clean code is to create software that is not just functional but readable and efficient throughout its lifecycle. Since the audience isn’t a computer but rather a real live audience.
Clean code is the foundation of sustainable software development. Below are a few reasons why clean code is important:
Technical debt can slow down the development process in the long run. Having clean code ensures that future modifications will be smoother as well as less costly process.
Clean code means that the developers are prioritizing clarity. When it is easier to read, understand, and modify code, it leads to faster software development.
Good code means that the code is accessible to all team members and follows coding standards. This helps in improved communication and collaboration among them.
Clean code is designed with clarity and simplicity. Hence, making it easier to locate and understand specific sections of the codebase. This further helps in identifying and resolving issues in the early stages.
Clean code facilitates unit testing, integrated testing, and other forms of automated testing. Hence, leading to increased reliability and maintainability of the software.
Below are some established clean code principles that most developers find useful.
Apply the KISS (Keep it simple, stupid) rule. It is one of the oldest principles of clean code. This means that don’t make the code unnecessarily complex. Make it as simple as possible. So that it takes less time to write, has less chance of bugs, easier to understand and modify.
This law states that the entity (class, function, or variable) must have a single, defined goal. It should only do one thing in one circumstance.
DRY (Don’t repeat yourself) is closely related to the KISS rule and Curly’s law. It states to avoid unnecessary repetition or duplication of code. Not following this can make the code prone to bugs and make the code change difficult.
YAGNI (You aren’t gonna need it) rule is an extreme programming practice that states that the developers shouldn’t add functionality unless deemed necessary. It should be used in conjunction with continuous refactoring, unit testing, and integration.
It means that the code should fail as early as possible. This is because issues can be quickly identified and resolved which further limits the number of bugs that make it into production.
This rule by Uncle Bob states that always leave the code cleaner than you found it. It means that software developers must incrementally improve parts of the codebase they interact with, no matter how minute the enhancement might be.
Apply the SOLID principles. This refers to:
S: Single Responsibility Principle which means that the classes must only have a single responsibility.
O: The open-closed Principle states that the piece of software should be open for extension but closed for modification.
L: The Liskov Substitution Principle means that subclasses should be able to substitute their base class without getting incorrect results.
I: The Interface Segregation Principle states that interfaces should be specific to clients instead of being generic for all clients.
D: The dependency Inversion Principle means that classes should depend on abstractions (interfaces) rather than concrete implementations.
A few of the best practices include:
Choose descriptive and clear names for variables, functions, classes, and other identifiers. They should be easy to remember and according to the context that conveys the purpose and behavior to make the code understandable.
Most programming languages have community-accepted coding standards and style guides. Some of them include Google Java style and PEP 8 for Python and Javascript. Organizations must also have internal coding rules and standards that provide guidelines for consistent formal, naming conventions and overall code organization.
Comments help explain the code. However, the codebase changes continuously so the comment can become old or obsolete soon. This can create confusion and distraction among software developers. Make sure to keep the comments updated. Also, avoid writing poorly written or redundant comments as it may increase the cognitive load of software engineering teams.
Magic numbers are hard-coded numbers in code. They are considered to be a bad practice since they can cause ambiguity and confusion among developers. Instead of directly using them, create symbolic constants for hard-coded values. It makes it easy to change the value at a later stage and improves the readability and maintainability of the code.
Ensure that you regularly refactor to enhance the structure and readability of the code. It also helps in improving its flexibility and maintaining code that is overly complex, poorly structured, or duplicated.
You can apply refactoring techniques such as extracting methods, renaming variables, and consolidating duplicate code to keep the codebase cleaner.
Version control systems such as GIT, SVN, and Mercurial help track changes to your code and pull back to previous versions, if necessary. Before refactoring, ensure that the code is under version control to safely experiment with changes. Moreover, it helps understand the evolution of the project and maintains the integrity of the codebase by enforcing a structured workflow.
Software developers can write unit tests to verify the code’s correctness as well-tested code is reliable and easier to refactor. Test-driven development helps in writing cleaner code as it considers edge cases and provides immediate feedback on code changes.
Code reviewing continuously helps in ensuring code quality by identifying potential issues, catching bugs, and enforcing coding standards. It also facilitates collaboration between software developers to see each other’s strengths and review mistakes together.
Typo’s automated code review tool not only enables developers to catch issues related to code maintainability, readability, and potential bugs but also can detect code smells. It identifies issues in the code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps the code error-free, making the whole process faster and smoother.
Key features:
Writing clean code isn’t just a crucial skill for developers. It is an important way to sustain software development projects.
By following the above-mentioned principles and best practices, you can develop a habit of writing clean code. It will take time but it will be worth it in the end.
Hope this was helpful. All the best!
Dead code is the most overlooked aspect of software development projects. They can become common when they evolve. A large amount of dead code can be harmful to software.
The best way to ensure this is to detect dead code in the early stages to maintain the quality of the software application.
Let’s talk more about dead code below:
Dead code can be referred to as the segment of code that is unnecessary for the software program. They are executed without their results being used or accessed.
Dead code is known as zombie code. Such a portion of code may have been part of earlier versions, experimental features, or functions that are no longer needed. If the dead code remains in the software, it can decrease the software’s efficiency and add unnecessary complexity to it. This can further make the code harder to understand and maintain.
The segment of code that is never executed under any condition during program runtime. It could be due to conditional statements, loops, or other control flow structures. Besides this, the issue may even arise during development because of coding errors, incorrect logic, or unintended consequences of code refactoring.
The portion of code that was once useful but not anymore. They have now become outdated or irrelevant due to changes in software requirements or function, technology, or best practices. Obsolete code may still be present in the codebase however, no longer recommended for use.
Code that was once part of a functional feature or system but is now left behind or isolated. This can result from changes in project requirements, refactoring, feature removal, or other modifications in the development process. As obsolete code, this code may still be present but no longer integrated or contribute to the application functionality.
Sometimes, developers ‘comment out’ code rather than deleting it to use it in the future. However, when they forget about it, it can facilitate dead code. While it is a common practice, developers must take note of it otherwise it can reduce code readability and maintainability.
Dead code majorly contributes to Technical Debt. While a small amount of technical debt is still fine, if it grows, it can negatively affect the team’s progress. This can also increase the delivery time to market to end-users and reduce customer satisfaction.
Hence, it is important to monitor technical debt through engineering metrics to take note of dead code as well.
Besides this, there are other reasons why removing dead code is crucial:
When dead code is present, it can complicate the understanding and maintenance of software systems. It can further lead to confusion and misunderstandings which increases the cognitive load of the engineering team.
Eliminating dead code lets them focus on relevant code that helps increase code readability, and facilitates feature updates and bug fixes.
Dead code could be a hidden backdoor entry point to the system. This can be a threat to the security of the software. Moreover, dead code includes dependencies that are no longer needed.
Removing dead code simplifies code complexities, and improves code review and analysis processes. This further helps to address and reduce security vulnerabilities easily.
Dead code disrupts the understanding of codebase structure. It not only decreases the development process but also developers’ productivity and effectiveness.
Eliminating dead code results in reducing the overall size of the code. Hence, it makes it concise and easier to manage which potentially enhances developers’ performance.
Duplicate code is a considerable strain on the software development process. However, when dead code is present, it diverts developers from identifying and addressing areas where code duplication occurs.
Hence, eliminating dead code avoids code duplication and improves the codebase’s quality.
When dead code is not present in the software, it allows developers to focus on the relevant active parts of the codebase. It also streamlines the process as there are no unnecessary distractions and identifies and addresses issues.
Dead code can often be removed through static code analysis tools. Automated tools such as code quality checkers can help in detecting unused variables, classes, imports, or modules. This allows developers to address and eliminate the dead code easily which reduces the development cost and improves the overall quality of the system.
However, the drawback is that during uncertainty regarding programming behavior, dead code may not be removed. Hence, static code analysis tools are not a complete solution.
Dynamic code analysis tools involve running the program to see which lines are executed and identifying which code paths are never reached. Hence, the code that is never executed or used in the codebase i.e. dead code is eliminated.
However, most of these tools are specific to programming languages.
Leverage version control systems such as GIT commits to identify code that was once active but now deprecated or replaced. Commits that were removed or modified could indicate areas where dead code be found.
In case of a mistake, the code can be retrieved from the version control system. Hence, less risky and easily manageable.
Through refactoring, developers carefully examine the codebase to identify sections that include unused or old code, unnecessary variables, functions, or classes. Hence, revealing dead code that can be safely removed. Moreover, refactoring aims to optimize code for performance, maintainability, and readability. This further allows developers to look out for inefficient or unnecessary code by replacing or redesigning these segments.
Code review is an effective method to maintain the quality of code. It promotes simplicity and clarity in the codebase. They can help in detecting dead code by applying best practices, standards, and conventions. However, when not automated, they can be time-consuming and harder to implement. Hence, it is recommended to use automated code review tools to speed up the process.
Typo’s automated code review tool identifies issues in your code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps your code error-free, making the whole process faster and smoother.
Key features:
In software engineering, detecting and removing dead code is imperative for streamlining the development process. You can choose the method or combination of methods to remove dead code that best aligns with your project’s needs, resources, and constraints.
All the best!
Time is a finite resource. Once it is gone, you cannot alter it.
This is why the calendar plays a major role in organizing and focusing towards our goals. However, it can become cluttered and overwhelming, when done incorrectly. It not only affects the engineering teams but also impacts business and client experience negatively.
Hence, the optimization of calendars is important for both engineering managers and developers.
In this blog, let’s dive further into the art of calendar optimization and various time management techniques.
Optimizing your calendar means making the most of your working hours. Effective time management allows you to create a micro plan for the day ahead and focus on high-priority tasks. Managing your time effectively reduces the risk of burnout and stress; helping in great productivity and alignment.
Another importance of optimizing your calendar is that it helps in defining the project goals. When they are clearly outlined, it lets you align your schedules with the project needs. Breaking them down into smaller tasks lets you focus on them more effectively and tackle critical tasks first.
Creating a daily schedule empowers you to spend more time on the project that matters and capture bigger opportunities. This further helps in prioritization and taking control of your day. Hence, reduces distractions and empowers you to do deep work.
Another benefit of optimizing your calendar is achieving a work-life balance. You and your team get time for both personal and professional tasks. This helps in becoming more productive and reduces stress and feeling overwhelmed throughout the day.
When your priorities are set and have a clear schedule, it helps you deliver high-quality commits on time. It makes your team reliable and improves their professional reputation which further helps in their career growth.
In 2009, Paul Graham (co-founder of Y-Combinator), coined the terms – Maker schedule and Manager schedule. These are two different styles of working that require different approaches.
Let’s understand both these terms in detail:
The maker schedule is designed for individuals who need long, uninterrupted slots for focus time. It allows them to enter into the state of flow to achieve peak productivity. For the developers who require deep concentration, this type of schedule lets them fully immerse in projects and let the creativity flow.
First things first, create a to-do list. See which tasks need to be done solo and which need to be collaborated. Now, prioritize them according to their due dates. Communicate with other team members for the collaborative tasks.
Set a specific time for deep work. You can add more than one per day since the tasks can stretch further. Use shorter blocks for meetings, communication, and other administrative tasks. Ensure that you communicate with others to minimize interruptions and distractions.
Bunch meetings such as team meetings, and one-on-one conversations together. However, schedule a 5-minute break between these meetings. This can reduce context switches and let you enter into a specific mental state. Hence, helps you with better concentration and productivity.
Don’t forget to take short breaks between your slots. This can be anything ranging from short naps to exercise. This helps in maintaining focus and better retention of information. As a result, it increases your energy and prevents burnout.
The manager schedule is for individuals who have various duties while handling teams and systems. It is usually for engineering managers and leaders since their day comprises meetings, managing teams, and their solo tasks as well. Their schedule is majorly based on coordinating with people who produce output. Hence, the schedule needs to be flexible yet maintain structure in their workflow.
Ensure that your meetings have clear goals and objectives. This helps minimize time wastage and keep discussions on track. Also, note that the meetings should be purposeful with a time limit. So, that they are straightforward and crisp.
Maker’s and manager’s schedules can contradict each other. Hence, have open communication about each other’s schedules. This allows everyone to not interrupt each other’s focus time and other important schedule. As a result, it reduces stress and pressure.
Make sure that you integrate your personal calendar as well so that your team knows when you are not available. It saves you and your team members from the trouble of rescheduling and streamlining planning without any stress.
Regularly review your schedule and adjust it accordingly. Check what’s working for you, and what can be delegated and eliminated. Align your time with evolving priorities and communicate the same with your team members.
In the current scenario, the maker schedule is difficult to follow in the organization. The culture is still meeting-heavy and prioritizes urgent and reactive tasks over deep work.
Below are a few of the ways to balance both approaches:
As the manager and maker schedules are different, async communication works better in this case. Tools like Slack and Microsoft Teams bridge the gap between these two frameworks. It creates an ecosystem where deep and creative work is prioritized yet allows you to be in regular contact with your team members without interruptions.
Meetings that don’t have clear agendas and comes between your team members’ schedule need to be assessed. Review them regularly so that you know which of them are overlapping and can disrupt the workflow.
To make it easier to assess, you can ask yourself three questions:
It is important to understand that creativity doesn’t always come at office hours. It can occur at different times and manners. Hence, communicate with your team members what are their focus time slots. A flexible schedule also allows them to respond to you at their convenient time while maintaining overall balance.
Synchronization is important for both schedules. In these cases, creating a feedback loop to discuss scheduling and priorities. Encourage open communication to see what works for you as well as for others. This lets team members have mutual understanding, empathy, and respect for each other’s roles and working styles.
Even after balancing the schedules, developers may still not have time to complete all their tasks.
Below are a few of the time management techniques you can experiment with:
This technique was coined by Dwight Eisenhower. This framework is specially built for individuals in leadership positions such as engineering managers, tech leads, and heads of engineering.
This time management technique helps to prioritize tasks based on urgency and importance.
It includes four separate quadrants:
This technique was developed by David Allen to make your tasks into a straightforward to-do list and break them down into actionable work items. It is a 5-step method that includes:
Getting things done helps developers if they feel overwhelmed and struggle to focus on a single task.
This time technique is an 80/20 rule created by Vilfredo Pareto. This states that 20% of our actions are responsible for 80% of outcomes. It allows you to prioritize tasks that are most effective at solving problems.
This can be done by:
This time management technique was created by Francesco Cirilio. It creates a sense of urgency and focus on a single task without interruptions.
In this technique:
This helps to eliminate burnout and improve performance and productivity.
Created by Taiichi Ohno, the main idea behind this visual time-tracking technique is to improve overall productivity and effectiveness. It helps to plan effectively, create SMART goals, and proper task delegation.
You have to:
There is no one-size-fits-all template for this technique. You can customize it according to your preferences and team size.
Optimizing the calendar is most important for engineering teams. They have a lot on their plate and have different working styles which allow them to create their best schedules and communicate with their team members.
Typo, an engineering management platform, allows engineering leaders to gain visibility on the team’s efficiency and workload. Book your demo and level up your developer game today!
Code Smells - A common encounter by developers and testers.
They are tangible and observable evidence that something is wrong with the application's underlying code. When left unaddressed, it can degrade the application's performance and increase the technical debt. This further makes it difficult for the software teams to provide value over time and deliver the product faster to the market.
Code Smell was first introduced by Kent Back in the 1990s and popularized by Martin Fowler’s Refactoring Book.
In simple words, code smell is a warning that the source code is messy and isn’t meeting the best practice standards.
However, Code Smell isn’t synonymous with bugs or errors. And they do not always mean that the code is wrong or broken. It highlights the presence of bottlenecks in the codebase that need immediate attention. If not, they can reduce the code quality, readability, and maintainability.
Moreover, Smelly code can easily become rotten code, when not taken care of in early stages. One of the main causes of code rot is technical debt. Hence, it is advisable to periodically check and fix them to prevent both code rot and technical debt.
Duplicated code is the most common code smell. It happens when a similar code exists in more than one area; most probably because the code was copied and pasted in different parts of the programme.
Although, it may look harmless but becomes challenging since the developer has to make multiple tweaks during feature updates. This not only decreases the code maintainability but also results in inconsistent application as the change wasn’t applied uniformly. It further increases the cycle time and is considered to be a business risk as well.
The long method is when the method contains too many lines of code. There isn’t any specific number of lines that are considered to be long. Some believe it to be 25 while other thinks 50 is too long.
This code smell also violates the single responsibility principle.
Long Method makes adding new features or updating existing ones challenging. It becomes harder to test, understand, and debug the code. This not only increases the cyclomatic complexity but also leads to unexpected bugs.
The code becomes dead when the developers forget to clean up the existing code, aren’t aware of the dead code in the first place, or can be in the form of old, commented-out code. The code is no longer needed yet it is still present in the application. It can be a variable, parameter, field, method, or class.
The amount of dead code in the application signifies:
This makes code hard to understand, increases bugs and errors, and more security vulnerabilities.
This code smell arises when a class exists yet doesn’t contribute seriously to the function or behavior of the software.
This increases the code complexity and clutters the code base. Hence, increasing the cognitive load for the developers which costs both time and money.
If left unaddressed for a long time, it can result in future risk i.e. Adding more functionality to the lazy class can lead to a bloated or poorly designed class.
Middle man occurs when the class delegates work to another class and it doesn’t have any independent functionality. A few of the reasons behind this code smell are:
This increases the code complexity and creates noise in the codebase. Further, it makes it harder to maintain the code and less efficient without adding significant value.
Primitive obsession is a type of code smell that developers can’t identify intuitively.
It occurs when a primitive value controls the logic in a class and represents complex concepts or behaviors. In simple words, when a code relies too much on primitive values.
Using primitives for everything is certainly a bad practice. This leads to poor readability, validation, and abstraction.
God objects are one of the common and problematic code smells. It is when a single class or program is central to the system i.e. handling diverse tasks that are not cohesively related.
It violates the single responsibility principle and creates tight coupling and challenges in code maintenance.
God objects use more unwanted resources even for simple operations and make it difficult to isolate and test components effectively.
This code smell arises when a class accesses the data or method of another class more than its own. It is because the class’ functionality is too closely tied to another class.
Feature envy violates the ‘Law of Demeter’ - The objects should only talk to their immediate friends, and not access their internal data and methods of other objects.
It can indicate a poor design that doesn’t include the encapsulation and cohesion of objects. It also results in high coupling between classes.
In this, the class contains many fields/methods/lines of code/responsibilities. This violates both the single responsibility principle and the open-closed principle.
It indicates a weakness in the design and makes it difficult for developers to understand, read, and maintain the code. Moreover, it increases the chances of errors and harder to locate them.
Note that, God objects often manifest as large classes. However, not all large classes are god objects.
The improper names of variables, classes, and functions indicate that the code is not clean. This could happen when it includes overly abbreviated names, non-descriptive names, or using different name schemes.
This leads to an increase in the cognitive load of developers and makes them suffer from ambiguity. It also lacks precision and leads to more confusion and errors.
Besides this, improper names make pair programming and knowledge sharing challenging for the developers.
Unfortunately, comments are code smells too. While it is a good practice, when it is overused for every step, it creates excessive noise in code. This decreases the readability and maintainability.
The comments can be inaccurate too since the reviewer shares them based on their perspective and understanding.
The comments should only explain the ‘Why’ and ‘What it is doing’ part of the code. And not explain ‘How’ the code works. If this is the reason, it could be that the code is not self-explanatory and needs refactoring. Besides this, long, dense blocks of text can disrupt the visual flow.
A long parameter list occurs when there is a long list of parameters in a method or class. Usually, the maximum number of parameters in a method should be 3 or 4. Otherwise, it tries to handle too many responsibilities.
It decreases the readability and reusability and makes it prone to errors and bugs. It further makes it harder to test and difficult to debug.
Besides this, It can become challenging to reuse the method in different contexts since it might require specific combinations of parameters.
Shotgun surgery happens when developers have to make lots of small changes to the codebase. The code smell often overlaps with other code smells, especially duplicate code.
It might be scattered around a much larger class or may even be in multiple classes or different parts of the codebase.
This type of code smell forces a clumsy, error-free approach and unnecessarily adds complexity to the codebase. The changes consume more time and increase the cognitive load of the developers since they have to remember the changes in various places.
Inappropriate intimacy occurs when a method has too much intimate knowledge of another class or method’s inner workings or data. It means bi-directional behavior between classes that are tightly linked to each other.
Changes in one module can easily break the other due to their deeply intertwined nature. This results in difficulty in enhancing/extending features and bug fixes.
Inappropriate intimacy also reduces modularity, flexibility, and testability.
A code smell is a common problem faced by developers, indicating the potential issues within a codebase. It is important to address them in the early stages, otherwise, it can reduce the code quality and slow down the entire development process.
Detect these code smells with Typo’s automated code tool which enables developers to catch issues related to maintainability, readability, and potential bugs. It identifies issues in the code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps the code error-free, making the whole process faster and smoother.
Key features:
Code review helps you to improve the quality and maintainability of your code. However, this process is challenging for both engineering managers and developers. While managers need to perform thorough reviews to ensure code quality, developers are usually overwhelmed when receiving feedback.
Engineering managers need to be courteous and respectful while offering constructive feedback to their developers. They must be clear with their feedback so that developers can understand your feedback in the right way and not take it negatively.
In this blog post, let’s explore the ways to provide code review feedback to developers:
Also known as peer review, code review is a key practice within quality assurance. It is a systematic examination of a software code by one or more individuals to improve its quality, identify issues, and ensure that it aligns with established coding standards and best practices.
Code reviews allow engineering managers and developers to detect issues and bugs in the early stages. So that the problems can be fixed before the end-users see them. Besides this, It allows developers to work with fresh knowledge, or else they may struggle to remember code, solutions, and reasoning.
Reviewing code regularly allows developers to learn more reliable techniques and best practices. It helps in gaining valuable insights into diverse coding styles and problem-solving approaches. Code review also allows engineering managers to mentor junior developers and foster a culture of continuous learning and growth.
Regular code reviews ensure the entire team adheres to consistent coding standards and best practices. This makes it easier for developers to understand and contribute to the codebase. Hence, they can write more readable and maintainable code over time. Besides this, it provides opportunities for refactoring.
Optimizing code through the code review process eliminates a significant amount of technical debt. It also detects code smells which are early signs of potential technical debt. Code reviews analyze the code and catch bugs to reduce the need for extensive rework later.
Always ask questions rather than demanding changes. It not only opens up a dialogue but also lets them think about input without being defensive. This also ensures that both parties can decide on the right course of action and know each other's perspective. When asking questions, developers can explain their thought process and rationale behind the code. This also fosters a culture of collaboration and highlights that nobody is always right.
Instead of saying ‘Change the variable name’, ask ‘I see you named this variable ‘Temp’. What about calling this variable ‘UserID’?
It is seen that written constructive feedback is usually taken negatively. Since the individual cannot see the body language, facial expressions, or tone of the other person. Words like just, easy, and obvious may seem belittling to the developers. This not only diminishes confidence but also introduces ambiguity within the team.
Make sure that you provide feedback in clear and complete language. And most importantly, Be polite!
This will help developers grow and work efficiently. Hence, enhancing overall code quality.
Don’t say ‘This fix is way too easy’. Instead, use this ‘I see a straightforward implementation here. Can you walk me through your decision-making process?’
Address the code directly rather than the developer. Discuss what can be improved in the code, not the developer’s skills or characters. Blaming them will lead to judgments, rejections, and defensiveness. They would avoid taking feedback positively.
Hence, ensure an objective evaluation of the code. Make this process a team sport and focus only on facts.
This will not affect any interpersonal relationships within the team and developers will take feedback seriously.
Instead of saying ‘You haven’t optimized the code efficiently’, You can say ‘This code hasn’t been optimized properly’.
Instead of just telling what improvements to be made to pull requests or code, explain the reason behind the change. Let developers know about the thought process and reasoning so that they look from the other’s perspective. Add a brief explanation along with the change mentioned.
Never assume that developers understand the ‘Why’ behind the change. Always clarify the reason so that they know where it is coming from.
This will help developers improve their skills and knowledge, enhancing code quality.
Don’t say ‘Update the variable names’. Instead, say this ‘Try adding descriptive variable names to enhance code readability and make it easy for other developers to collaborate and maintain the codebase.’
Clarify to developers that it is not a universal statement or generalization. Rather, it’s an observation or one perspective as per the code written.
Hence, use ‘I’ while writing constructive feedback. It not only fosters an open and receptive environment for discussing code changes and improvements but also makes it easier for both sides to look for solutions.
This makes developers less defensive about their work and more open to pair programming and learning opportunities.
‘The code is hard to follow’ should be changed to ‘I am finding this flow of code a bit challenging to follow.’
Always suggest solutions and guidance on how they can improve. It could be a framework, method, or API. It doesn’t mean giving a complete solution but sharing an improvement strategy. This will save developers time in implementing these suggestions and address issues (which they might have overlooked). Also, they will be able to learn new techniques, best practices, and coding standards to improve their coding skills.
Use examples as well so they understand the solution practically.
If the loop structure is inefficient, suggest a solution like ‘Consider using a 'for-each' loop instead of a 'for' loop for better readability and concise code.’
Apart from solutions, share learning resources with them. It could be related to the areas where developers need improvement, new industry trends, or code review best practices. It will help them stay updated with the current trends and improve their understanding of specific technologies and frameworks. Resources such as relevant documentation, tutorials, and online courses work wonders.
This will help developers take ownership of their learning and foster a sense of autonomy.
Instead of simply pointing out the developer’s blindspot, for example - Not familiar with the new framework’s syntax. Write this - ‘I noticed some challenges with the syntax of the new framework. I recommend checking this document ‘Framework Documentation.’ as it provides clear examples and explanations.’
Review code frequently as it reduces the need to make the process lengthy. Long code reviews would be overwhelming and confusing for developers since they need to make a lot of changes and improvements altogether. Even after doing it frequently, the code reviews take hours, break it down into small parts.
Smaller code reviews allow developers to understand the reason behind the constructive feedback. Hence, they can make changes to the code without any dilemma or misunderstanding.
Suppose a developer has submitted a large pull request that considers various features and changes.
Instead of sharing feedback all at once, say this ‘Let’s first focus on the changes related to the new feature implementation. Once done, we can move on to reviewing the improvements in the existing code.’
Effective code reviews take place when both positive and constructive feedback is included. Developers may make a few mistakes here and there. But, this doesn’t come from a bad place. They are improving, growing, and giving their best.
Hence, pat their backs on the things they have done correctly. Positive feedback creates a culture of recognition and gratitude which improves collaboration and communication.
This also lets development teams to continue put efforts and strive for excellence.
When recognizing their efforts, say this ‘Nice job on the new feature. Your attention to detail and writing readable code is commendable.’
Use code review tools to help in assessing the quality of code. These tools can help in spotting bugs and vulnerabilities, detecting code smells, syntax errors, security vulnerabilities, and many more. It also gives visibility into changes, hence, making the feedback more focused and contextually relevant.
These tools also ensure that the code adheres to the coding standards and best practices.
Typo’s automated code review tool identifies issues in your code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps your code error-free, making the whole process faster and smoother.
The code review process might be time-consuming, but, it is rewarding too. It helps in knowing whether the code needs refactoring, has bugs or errors, or anything else that could hamper its performance.
Follow the 10 tips mentioned above to encourage collaboration, open communication, and knowledge sharing among developers.
Happy reviewing!
Product Management and Software Engineering are among the roles that drive innovation for a product. And today, these roles are intertwined in ways that responsibilities and capabilities can seem blurred – which leads to the question, which role is right for you?
Product Managers answer the “why” and “what” questions about a product, while the Software Engineers answer the “how” – both important in software creation.
Choosing between product management and Software Engineering can be challenging since they are crucial for businesses. To help you make an easy decision, in this blog, we break down their roles, career responsibilities, trajectories, differences in day-to-day work, and where they are similar. Let’s dive in!
The Product Managers serve as the guiding strategic navigators of innovation and steer products from a mere idea, conceptualize it, and take it all the way to market launch. They provide the blueprint for the product’s path from inception.
Unlike Software Engineers, the Product Manager role extends beyond coding. They combine business acumen, technological insights, and customer-centric thinking and translate into the fulfillment of a product.
They deep dive into market analysis and identify user needs, effectively shaping the product roadmap. With this information, Product Managers align customers with business objectives. The product role also includes fostering a collaborative culture between engineers, designers, sales, and marketing teams while staying true to ever-changing market dynamics through agile methodologies.
They drive teams toward a shared goal while crafting a roadmap.
The Product Managers serve as the guiding strategic navigators of innovation and steer products from a mere idea, conceptualize it, and take it all the way to market launch. They provide the blueprint for the product’s path from inception.Unlike Software Engineers, the Product Manager role extends beyond coding. They combine business acumen, technological insights, and customer-centric thinking and translate into the fulfillment of a product.They deep dive into market analysis and identify user needs, effectively shaping the product roadmap. With this information, Product Managers align customers with business objectives. The product role also includes fostering a collaborative culture between engineers, designers, sales, and marketing teams while staying true to ever-changing market dynamics through agile methodologies.
They drive teams toward a shared goal while crafting a roadmap.
A Software Engineer evolves from an entry-level position to senior and staff levels. This path can lead them to management roles. They can manage engineering teams and progress to positions like VP of Engineering, CTO, and Director.
However, through this transition, they must develop varied skills to support their growth. From purely technical skills, their role can evolve to people management, a distinct skill honed over time.
Product Managers also grow similarly in their career paths. They move from being individual contributors to leading fellow Product Managers. It often involves market research and product marketing. Their trajectory then moves into the business aspects of the organization. Many of them move into roles like Managing Directors or Vice Presidents. In such roles, they oversee several divisions and business lines.
In these roles, Product Managers influence the product strategy and the marketing, sales, and finance functions in line with the company’s goals.
To know which role is right for you, understand what the day-to-day responsibilities of the roles look like:
Software Engineers and Product Managers drive the creation and evolution of software products. However, each has a distinct set of responsibilities, strategies, and perspectives. A project needs a blend of these roles and their unique skill sets.
When working as a software developer, it's important to acknowledge and appreciate each team member's unique roles and responsibilities. Even though everyone has specific tasks, teamwork is still crucial to success. That's where a Product Manager comes in - as a mediator between stakeholders and the engineering team, they gather feedback and ensure everyone is on the same page.
While the PM might help push specific deliverables, it's ultimately up to the engineering team to execute them. That being said, the PM might be held accountable for the project's overall outcome, especially regarding user satisfaction and management expectations. It's crucial to understand the difference between responsibility and accountability in any project and to work together to achieve success.
Software Engineers and Product Managers have contrasting approaches to tackling gaps in products. While engineers focus on technical obstacles and evaluating technologies, Product Managers prioritize bridging gaps and identifying opportunities. They streamline user scenarios, engage with users, and ensure alignment with key stakeholders. Collaboration between the two roles leads to impressive outcomes, with PMs providing valuable input and engineers making technical trade-offs to create optimized features.
It is essential to recognize that different roles in product management have varying timeframes. Software Engineers (SWEs) typically operate on regular sprints, often on a weekly or bi-weekly basis, which enables them to structure their working schedules and remain on top of their tasks. In contrast, Product Managers (PMs) have more flexible timelines, as their responsibility lies in steering long-term strategies.
While PMs must pay attention to immediate tasks and customer feedback, they must also align with engineering sprints to provide the necessary specifications and artifacts. To be a good PM, it is essential to support the engineering team, and engineering timelines should influence their timeline but not necessarily be linked to them.
As a Software Engineer, it can be challenging to keep up with the frequent deliverables that come your way. From minor bug fixes to complex feature releases, each deliverable can impact the user differently. Some tasks, like maintenance tasks, may seem insignificant, while others can be game-changing for the product.
When it comes to customer-facing products, the release cadence may be less frequent, but the user impact of each new feature or improvement can be significant. It's essential to consider the user's perspective when prioritizing and planning deliverables to ensure a positive experience.
Software Engineers typically have a one-month ramp-up period before their responsibilities increase. At the same time, project managers may require up to two years, especially in larger companies. This is due to the complex decision-making involved in project management and the need for a deep understanding of the context. Although Software Engineers and project managers can impact user experiences, project managers are generally responsible for end-to-end user scenarios.
Let's simplify each role to help you decide which suits you best.
Do you enjoy strategizing, collaborating, and connecting user needs with product plans? If so, Product Management might be your fit. As a Product Manager, you'll shape the "what" and "why" of a product, drawing insights from user research. You'll understand customer desires, align business goals, and guide teams, from concept to product launch. If you love crafting solutions and teamwork, this could be your calling.
Are you intrigued by coding, solving problems, and building software solutions in a technical role? Software Engineering might be your compass. Software Engineers craft the "how" of products by turning ideas into functional code through their expertise in software development. If you thrive on coding challenges, value technical expertise, and want to create digital innovations, this path could be for you.
Remember, these paths often blend, and you're in control. Consider your strengths. Do you want to explore code and technology? Software Engineering might be your choice. Or do strategic thinking and teamwork drive you? Product Management could resonate.
Both roles demand learning and adaptability, shaping our tech world. As you gain clarity, let your choice align with your ambitions, guiding you toward a fulfilling career in the ever-changing tech landscape.
If you are passionate about technology, product management, and engineering are fascinating fields. They provide unique paths to explore, each with its challenges and rewards.
Whether you thrive on navigating the strategic landscape of product development or find joy in the creative process of coding, your choice of focus reflects your aspirations and strengths. By embracing the path that resonates with you the most, you can build a fulfilling and impactful career in this exciting industry.
Code rot is a common problem among engineering teams. It can compound unless it is well-managed.
Just like how we need to nurture our plants to grow or else they will be withered. The same should be done with code, otherwise, it will rot.
So, let’s delve deeper into the concept of Code rot, ways to recognize it, and how to address it.
Also known as software rot or software decay, It refers to the deterioration in the performance of a piece of code. It doesn't mean code doesn't break down or rot away. Rather, the quality of the code starts degrading over time, emphasizing the importance of clean code practices.
This further makes the software faulty, unusable, or need upgradation. If not taken care of in the long run, it can also directly impact the team’s productivity and morale.
Active rot shows signs of code while they are actively handled and maintained. Also known as Gradual Decay, these codes slowly worsen in small details. The common type of code rot can be found in every code base to a varying degree. This is because most software requires constant updates and bug fixing. Hence, deviating the program from its original design.
Dormant rot is easy to detect. This code isn’t being touched constantly which makes them useless as the rest of the application upgrades. The reasons could vary. A few of them include API no longer working, Hardware and platforms have stopped working, and missing device adaptations.
In this case, the code breaks in many places whenever a change is made. The code isn’t stable as software becomes difficult to maintain. When the code is fragile, every new change introduces several new defects. Even when the areas aren’t related to each other. They can be either detected early by an automated testing suite or found in production by end-users.
Declining software metrics don't always indicate code rot, but they can be a warning sign that the code needs to be reviewed. Sometimes, it's a slow deterioration, showing that the code isn't as healthy as it once was, and action should be taken to resolve it. A few of the metrics that can collect software codebase health data include Coupling, Cyclomatic Complexity, and Test Coverage. These metrics provide valuable insights into software complexity and can guide improvements.
When the code is hard to change, it can be a warning sign of code rot. Even when it is a simple change, it takes longer than expected. Moreover, one change may lead to other changes as well. The code becomes less adaptable to changes and prone to errors, instability, and crashes. As a result, this leads to a slowing down of the development process.
In continuation of the above point, code rigidity can also increase the time to deliver value. As the code is in an unhealthy state, more time will be needed to add new features. Hence, it takes longer to ship new features to the customers. Moreover, the developers may fear managing non-critical issues as they aren’t sure of the full impact of the change.
When the documentation isn’t updated or maintained for a long time, it gets out of sync with the code. This makes it misleading. As a result, it creates confusion and errors for developers to rely on it. If the documentation remains outdated for a long time, it can make the end users unhappy with the product.
You can start by defining what Healthy software stands for in your organization. Establish a set of common coding guidelines and practices for your team members. It allows them to be on the same page and move in the same direction. Moreover, it creates a social contract between the team and lets them consistently write code.
Software metrics may not necessarily identify code rot. But it can help in knowing the quality and health of the codebase. Various metrics such as cycle time, code churn, and cyclomatic complexity let the developers know how the code is performing. It can identify code smells and technical debt, track their changes over time, and much more. Hence, helping in further inspection.
Software metrics can also help in knowing the blind spots within your software development. Hence, it helps developers to know which areas need refactoring to enhance the overall quality of the code. Refactoring them in small, frequent iterations lets the code adapt better to new environments and improves its quality and longevity. This approach also assists in the gradual improvement of the code base and keeps it manageable, ensuring that your test suite remains effective.
While manual testing may take a lot of time, you can go for automated testing of the code. However, ensure that the code is written with testing in mind. It lets you know whether the code is working as expected. Moreover, if any recent changes are made, automated testing lets the developers know any previously working functionality has been affected. Hence, helping in detecting the issues early.
Lastly, after hiring the right set of developers, ensure that you train them regarding coding guidelines. Make them understand how refactoring should be done often and coding best practices. Try aligning them with other developers. Create a culture of continuous learning and foster open communication in your organization.
While code rot is a universal problem, It can still be prevented. Take care of your code base often. If any issue is detected, take the necessary steps at the earliest.
Typo, an intelligent engineering platform, can help in identifying SDLC metrics. It can further help in detecting blind spots and reducing code rot.
Speed is crucial in software development, but it’s not the only thing that counts. Without clear direction and purpose, your team may struggle to stay on track and deliver valuable results. This is where scrum velocity can help you.
So, let’s delve into the concept of Scrum velocity, how it’s calculated, and why it’s a game-changer for Agile teams.
Velocity is speed with direction, and development speed without direction is an utter waste of time. Therefore, team velocity in scrum development is the team’s capacity for producing useful, working software. Simply put, scrum velocity is one of the key agile metrics that represents the capacity of a development team to achieve a given purpose.
For example, if a team completes user stories with a total of 30 story points within a two-week sprint, their velocity for that sprint is 30.
To calculate velocity in Scrum, follow these key steps. First, determine the unit of measurement to track progress and select a time frame (iteration or sprint) for the calculation. Once these basics are in place, track completed story points.
Story points are used in Scrum to estimate the size or complexity of user stories or backlog items. Teams can compare and prioritize different pieces of work based on their difficulty level.
Track progress during the sprint by recording the total number of story points completed. This allows accurate calculation of velocity at the end of the sprint.
Velocity is measured per sprint and used for planning and productivity measurement. Tracking velocity, a fundamental Scrum metric, helps forecast how much work can be accomplished in future sprints and informs release and iteration planning. If there is a user story with 4 story points and another with 5 story points, then this sprint’s scrum velocity is 9 (4+5) by adding both story points.
Velocity tracking is one of the key agile metrics used in Scrum and other agile frameworks. Below are a few benefits of velocity tracking:
Monitoring velocity is essential for boosting team productivity and improving forecasting and planning. By tracking velocity across various sprints, the team can establish a standard and use it to estimate the amount of work they can handle in future sprints. This ensures that they can set practical goals and make informed commitments to stakeholders.
By using velocity tracking, the team can detect patterns and trends in their performance. They can also examine the factors that cause fluctuations in velocity, such as changes in team structure, task complexity, or external dependencies. Through iterative development, the team incorporates lessons learned from each sprint into the next, fostering a cycle of continuous improvement. By better understanding these factors, the team can refine and improve their procedures, resulting in more dependable and consistent delivery.
When teams can track their velocity and see improvements or consistency, it significantly impacts their motivation and overall satisfaction with their job. This can also foster a spirit of collaboration and transparency within the team as they work together to achieve their goals and continuously improve their velocity.
Monitoring velocity provides an exact measure for stakeholders and management to track team progress, capacity, and abilities. It encourages transparency and fosters trust between the team and stakeholders, leading to successful collaboration.
While velocity is a valuable metric for scrum teams, setting it as a target can create undue pressure and even lead to punishment for team members who fall short. A more compassionate approach focuses on tracking metrics and identifying any underlying causes of issues. This way, your team can improve their processes, eliminate bottlenecks, and incorporate new tools to enhance their skills over time.
It’s understandable that teams approach projects in their unique way, so it’s not always fair or practical to judge them solely based on their speed. A team’s velocity can be influenced by various factors, including the project’s complexity and the team members’ individual skill sets.When calculating scrum velocity, it’s important to remember that story point estimates can be subjective. Comparing teams solely based on velocity can lead to a negative work environment, internal conflicts, and low morale. It’s better to use this measure to navigate situations within a team rather than to compare teams against each other.
When you introduce the concept to the team, it’s understandable that every team needs time to work together effectively. Whether they’re a new or old scrum team, they would take time to understand new complexities and create action plans. It’s unrealistic to expect them to perform at maximum velocity right away, and it’s common for leaders to have unrealistic expectations based on an outsider’s perspective. Only the scrum teams and managers working on the project can accurately estimate true scrum velocity, as they’re facing internal roadblocks and several complexities.Therefore, providing them with space and time to work together effectively is crucial. Business leaders who fail to acknowledge this may unknowingly hinder their team’s progress and prevent them from moving in the right direction.
Scrum teams must allocate time for unforeseen activities, such as addressing technical debt and critical bugs reported by customers. But teams who only focus on scrum velocity need more investment in quality.
Neglecting these essential tasks can lead to a decrease in the quality of the final product and cause issues for future timelines. Short-term focus on velocity can hurt progress and ultimately harm business success. Therefore, it’s crucial to invest in the necessary resources for scrum teams to work effectively and prioritize quality over speed.
While some team leaders rely on scrum velocity for project completion estimates, this may not align with Agile principles. Factors such as changing requirements, short development sprints, and unpredictable variables affect velocity.
Therefore, depending solely on a static tool or metric for progress measurement may not be an efficient choice, especially if it only provides an estimation instead of a precise timeline. It’s important to remember that scrum velocity can only offer an approximate timeframe for project execution and should be treated as such.
Overemphasizing scrum velocity as a performance metric can lead to inaccurate predictions and frustration when tasks take longer than expected.
Moreover, assigning blame for incomplete stories can create negative feelings among team members. To avoid these issues, remember that velocity should only be used for prediction purposes and not for comparison or competition. Ultimately, the goal of development should be predictable progress rather than constantly increasing speed.
While velocity provides a general sense of how much work has been completed, it doesn’t give the full picture. You must account for factors like technical debt, bug fixes, and non-functional requirements to ensure you get all the important details that impact the overall value the team delivers. It’s essential to look beyond the surface level and consider the specifics of what was achieved and the quality of the work.
As part of sprint planning, the Scrum Master plays a crucial role in facilitating these retrospectives and ensuring that the team's feedback is incorporated into future sprints.
As an Agile team, it’s essential to recognize the significant role that velocity plays in your success. By understanding your team’s past velocity, you can better plan for future sprints and set realistic goals everyone can commit to within the Scrum framework. This helps keep everyone on the same page and provides a clear measure of your productivity and progress over time.
It also enables you to make data-driven decisions and aim for constant improvement. Ensure you look at scrum velocity objectively and not as a sole indicator of performance and productivity.
By following some simple tweaks to your process and journey with scrum velocity, you can achieve your goals efficiently.
Developers are constantly juggling between one or the other tasks. It may seem a ‘normal’ thing, but it can harm the software development process. If not measured timely and properly.
There are many metrics that engineering managers can take note of. But, here we will be discussing one of the important yet overlooked metrics in software development – Code Churn.
In this blog, let’s dive deeper into code churn, what causes high code churn, and how you can prevent it:
Also known as code rework. It is when a developer makes changes to a specific piece of code including a file, a class, or a function during the development process. Although, it is a normal thing, but also depends on when and why it is taking place.By this, we mean that testing, reworking, and exploring various solutions to a problem is fine. Especially, during the beginning of the project when code doesn’t have a clear solution.
It is healthy and expected unless it surpasses 20% – This is when it is a problem. The lower the code churn, the closer you get to a release date.
Common workflows and dynamics that can result in a high churn rate include:
Prototyping is a natural and healthy trend. It is usually seen when there is a new or unfamiliar project. During these times, the churn rate may rise to 60-80% and this is not unusual.
Apart from prototyping, redesign, and POCs are all examples of where large chunks of code are rewritten. Hence, it is fine to allow developers the time and space to research and experiment.
But, if it continues for an extended period beyond what was expected then it is a cause for concern. It could be that the developer is not able to comprehend the specific components or the entire problem. Or the problem could be complex.
One of the main factors behind high churn rates is inconsistent or unclear requirements. It further spreads to subsequent phases of software development which compromises the quality of final products.
It could also be that the requirements change midway through the work which is another reason for high code churn. Due to this, developers may rely on their best guess to interpret and fill in any gaps. As a result, some assumptions could be wrong too.
This further damages the morale and progress of the development team.
Uncertain developers may also impact team performance as they juggle between various approaches, such as:
Any of the above leads to subsequent changes in the code base which results in a delay in progress. Since decisions are constantly revisited or revised.
Complex tasks are another reason for higher code churn. Since the developers are continuously exploring and backtracking the project, it is not unusual that churn rates may exceed the desired level.
But, as mentioned above, if it goes on for too long, then it is a cause for concern. It could be that developers may not have the resources they need or may require additional help.
It can also increase Technical Debt resulting in high code churn. Developers take shortcuts and make compromises that hinder the entire development process.
Software developers are more likely to be burnout due to their busy work schedules. Even when enough resources are available and they have the required skills, developers who are burnout may not be able to do their tasks efficiently.
It can further result in becoming disinterested in work, failing to show up, and increasing the rate of presenteeism. Hence, developers may want to change their jobs resulting in an increased turnover rate.
When former developers resign, new ones replace them. They would need time to familiarise themselves with the existing code and team. Hence, it leads to knowledge loss which causes potential errors or inefficient changes.
Minimizing and managing code churn is done by measuring it. This allows you to prepare to take things in control when there is an increase in code churn.
Measuring it helps you understand the software development process and know how many times code is changed. It also lets you see in-depth insights into internal and external hurdles allowing you to create actionable plans.
It is the measure of the number of times the developers made changes to the file in GIT control.
The number of lines of code that were added to files for the code that was written recently.
The measure of lines of code that was deleted from files within three weeks of writing the code.
The measure of lines of code that was modified within three weeks of writing the code.
The total of lines added, lines deleted and lines modified.
High code churn usually arises when requirements are not properly defined. Hence, it is important to take sufficient time to understand the requirements.
In case, the requirements are ambiguous, ask for additional clarification and review it once before starting with the project. Make sure that every team member is on the same page and knows what needs to be done.
Also, aware clients and stakeholders as well of how mid-stream changes can result in slow delivery and increased time.
Higher code churn usually occurs due to ineffective planning. Always use data-driven and factual insights to plan team and task allocation for reducing code churn. It includes thorough pre-development preparation, comprehensive requirement analysis, and careful project scheduling. This reduces the likelihood of frequent code changes or major rework during later stages.
Moreover, effective planning allows software engineering teams to navigate new areas of the codebase.
Understanding the root cause lets you identify a long-term solution that helps in improving the quality of the database.
For example, if you are aware that the developers are still lacking needed skills, you can involve pair programming sessions with senior engineers.
Failing to address the root cause makes you constantly make changes to the codebase which lets you create a cycle of rework and inefficiency, potentially leading to bug fixes and future quality problems.
Usually, developers spend more time reading code than writing it. Hence, ensure that the code is readable to all.
It could be that developers may have different professional qualifications and work experience. Their language preference and writing styles could be different from each other. Hence, implement standardization in the workplace. And ensure that your team knows about it.
Also, select coding style guides. It will allow developers to read code easier and faster. It further helps in promoting best practices and coding techniques, leading to low code churn.
The code review process lets developers catch errors early in the development process. This further helps in improving code quality.
Apart from this, code reviews also allow team members to identify areas where code needs refactoring. As a result, helping them to prevent the need for extensive rework later. Code reviews let developers get honest feedback at the right time.
Typo’s automated code review tool identifies issues in your code and auto-fixes them before you merge to master. This means less time reviewing and more time for important tasks. It keeps your code error-free, making the whole process faster and smoother.
High churn can signify that developers are innovative and determined. But, when it goes on for a long period, there is a problem that needs to be addressed as soon as possible.
Pull requests are made on git to work with a team collaboratively. In most open source projects, the contributors request for the review and acceptance of a branch, and then depending on the vitality of the code, it is either accepted into the code or not.
However, what happens when it is not merged and needs to be reverted? This is why we’ll tell you how to revert a git pull request.
You want to avoid being in a position of reverting the pull request as often as possible, but sometimes, you just have to do it. And a lot of situations are beyond your control. So here are some of the reasons:
There are multiple ways you can revert a git pull request; some are safer than others. Here are some of the methods:
Whenever a revert is made, it creates one revert of the merge commit.
If you have write permissions, go ahead with the following steps:
The Git revert command helps you create an inverse to the introduced changes and adds a new commit with these changes.
Here are the steps:
This step doesn’t remove the changes made but adds changes to negate the pull request.
The previous method altered the new reality caused by the merged unneeded pull request, but Git reset is like going back in time to change what was done.
While this might have unintended consequences, it might still be a route you can take if needed, and here is how you can do it.
Pull requests are an integral part of working collaboratively, and merging them by mistake or without enough review can cause many issues to the codebase. Then reverting this process can have other consequences you want to avoid. Therefore, have an internal process to merge pull requests. Ensure everybody is on board with the code reviews needed for the process and a checklist to denote when a merge is acceptable.
We at Typo can help you improve your engineering processes and deploy quality code faster. You can quickly get started with our tool on Git for a seamless experience.
Counting lines of code can be used as one of the metrics to assess your developers' productivity and the efficiency of code bases. Therefore, in this blog, we dive into the different methods to count lines of code and what we think about this metric.Let’s dive in!
There are several ways to count LOC, some more efficient than others with different objectives. So we have a list for you to use the best method that suits your needs.
Counting lines of code manually involves going through each line of code and tallying the lines while excluding comments, blank spaces, and non-executable lines.To do this, open the source code file and count the lines with a paper or text editor. Go through it line by line and check for executable code.Once you are done, note the total count.However this method might sound simple, yet it is tedious and prone to errors. Automated tools are more accurate and efficient, and we will discuss them in the following methods.
The Count Lines of Code (CLOC) command is a tool that automates counting lines of code.Here's how to use the CLOC command:
Here is an example of the tool and its results.
The automated categorization of lines into different types and comprehensive statistics using CLOC makes it superior to manual counting. You can trust the reliability and efficiency of this tool to save you a lot of time and effort.
While the above methods show the lines of code, if your code increases in more blanks, comments, and statements, then the number gets inflated without any value added to the functionality.Therefore, statements count is much more helpful in understanding the executability and functional efficiency of the code.In languages like C, C++, C#, or Java, a statement ends with a semicolon (;). And in languages like basic and VB, several statements can be added with a colon (:). Thus, the way it is done differs, but the logic remains the same.The executability (XQT) is calculated by dividing the number of executable statements (STMTX) by all the statements (SMT).Here are some specifics of this method:
While this does provide code complexity information, it still needs to be a fool-proof method. Factors such as data dependency and error handling can hamper the executability of the code.
When measuring developer productivity, it's crucial to select the appropriate metrics. Simply counting lines of code may not be dependable. Instead, experts advise measuring the number of executable statements within the runtime environment, which is a more comprehensive and precise comprehension of progress.Here are the steps:
Following these simplified steps, you can easily count the lines of IL code in your program.
Counting lines of code has been a long-time metric; however, every tool and method gives different answers.Using it as a tool for productivity can be problematic because it is not comparable or fair unless you compare the same team’s code within the same team for the same code, language, and style.Here are some more points for you to consider:
LOC can give you glimpses into code complexity, code length, and executability, but that’s where its importance should stop. Typo’s CEO and Founder, Kshitij Mohan, says, “Measuring developer productivity solely by lines of code is like assessing a painting by its brushstrokes. It focuses on solution complexity rather than the complexity of the problem at hand. And like most metrics, it means very little without context.” Therefore, we believe you can count the lines of code all you want, but don’t use it as a metric to determine which code is better or which developer is more productive. Use it as intended – as a metric to help you along the way.
Moving to a different role in your career is always exciting, but that doesn’t mean you can’t also have some self-doubt and anxiety. As a programmer, your responsibilities are more focused on your deliverables and some amount of collaboration with your team member. However, as a manager, your duties will look different.
Therefore, in this blog, we break down some tips to make the transition from a developer to a manager smooth for you.
Moving from being a programmer to a manager can seem daunting, but it's not necessarily a one-way street. With the right approach, you can transition safely using a trial period, and this allows you and your manager to assess if the new role suits you.
It's also beneficial to develop your soft skills during this time by mentoring a junior employee. This is an excellent opportunity to experience management and take responsibility for someone's career growth.
Working closely with your mentee enables you to evaluate your suitability for a management role without formal commitment. If your mentee responds positively to your mentorship style, it can be a strong sign that management is a good fit for you. Remember, this is a journey, and it's okay to take your time to determine if this is the right path for you.
As someone who understands the ins and outs of software development, you know that producing quality code and delivering outstanding products requires the collective efforts of your team.
As a manager, your role is pivotal in ensuring that your team has all the resources needed to succeed. While hands-on work may still be necessary, a significant part of your job involves managing people and projects. This could mean supporting team members who may be going through a tough time or encouraging someone contemplating leaving to stay.
It's a challenging experience that requires emotional investment, but it's crucial to remember that your efforts play a significant role in keeping your team happy and productive. Remember, as a manager, you're not just overseeing a team but also responsible for their well-being and success.
In today's hybrid or remote work environment, your communication skills are more essential than ever, especially when it comes to writing. As a manager, you spend a significant amount of time typing away on your keyboard, exchanging and managing information. To sharpen your communication skills, it's essential to set clear, measurable goals around how you respond to emails and messages.
As a new manager, you'll quickly learn that a timely response is often more valuable than a delayed one that's been meticulously crafted. Finding the right balance between timely and thoughtful communication is critical to effective management.
Additionally, as a manager, you must be more empathetic in your communication. This skill isn’t merely about language; it’s also about the tone you use and the words you choose while communicating. It will allow your team to be more transparent with you and aid in a more cooperative team spirit.
As a manager, it can be a real challenge to balance your time between overseeing your team's work and getting your hands dirty with coding. While you have a range of important tasks to manage, such as setting project goals and managing resources, these duties can often limit the time you have available for coding, which can be frustrating.
In addition to these managerial tasks, you may also find yourself supporting and mentoring your team members, engaging in strategic planning activities, communicating and collaborating with stakeholders, and managing administrative tasks. All of these activities require your presence and engagement, which can further limit your time for coding.
It's important to remember that the amount of coding you do as a manager can vary depending on the size of your team, the nature of your projects, and the structure of your organization. In some cases, you may still have opportunities to contribute code on a limited basis, particularly in smaller teams or more hands-on managerial roles.
Even though you may code less as a manager, your technical expertise and understanding of the development process remain incredibly valuable in decision-making, architectural discussions, and providing technical guidance to your team. So, don't worry, you may not be coding as much as you used to, but your contributions are still significant and appreciated by your team.
Establishing trust within your team is crucial as a manager. It's essential to provide your team members with clear instructions and expectations while assigning tasks based on their skills and expertise.
Ensuring open communication is key, and creating a safe space where team members can speak freely without fear of judgment or backlash is essential. Because remember when you were a developer and maybe someone didn’t trust you enough or when you felt micromanaged? Yeah, you don’t want your team members to feel that way.
Giving them the freedom to make decisions and solve problems within their areas of responsibility is essential too. Also, don’t forget to celebrate their accomplishments, support professional development, and practice transparency are all vital components to building trust.
Remember that trust takes time to develop, so lead by example and show your team members that you trust their abilities and support their professional growth. With these efforts, you can create a positive and productive work environment for your team to thrive.
As a manager, managing your time effectively can be a challenging task. Unlike individual contributors, you may have limited time to focus on creative problem-solving. This means you must protect your team members' time by minimizing unnecessary meetings or interruptions. To ensure maximum productivity, many managers schedule all internal meetings on a specific day of the week. As a great manager, you can get into the "flow" state quickly. By working in shorter blocks of time, usually around 20 minutes, and focusing on one task at a time, you can achieve this. By switching between tasks without losing productivity, your team can benefit from a positive and productive work environment.
A new role can be daunting, but if that’s what you want, then it can also be an exhilarating experience. Remember always to keep learning and focus on your team; you will know how you are doing as a manager in how they collaborate with you and each other and how openly they communicate with you. It can be tricky initially, but by improving, you can surely be successful.
While thinking about how to be a better manager, you can also include tools that can help you and your team. A platform that allows engineering teams to maximize productivity and reduce stress will be a game changer for your new team. Typo can be your friend in this process; you can schedule a demo to learn how!
‘Product Hunt’— a popular destination for startups, early adopters, and investors. It is considered to be a go-to platform that turns your product into a business if done right.
Considering that, we launched ‘Typo’ on 22nd February 2023 on Product Hunt.
To our surprise, it exceeded our expectations and we became product #1 on launch day with ~2000 upvotes. But, that’s not all! We also became the #1 product of the week and #2 product of the month.
It not only gave us 300+ signups globally but our website traffic was also boosted by 8x.
In this article, we have shared our extensive learning that made our product a success. Hope it helps everyone who is planning to launch their product soon on a product hunt.
We are proud of how ‘Typo’ launch became a huge success. But, it wouldn’t have been possible without the Product Hunt platform. We prepared everything for our launch, the Product hunt gave us much-needed attention and visibility.
Before you start with the pre-launch preparation, know what your goal for your product is. I.e. Get clear on what outcome you want to achieve!
Our main aim was to find early adopters who can give us product feedback.
Following are the few objectives that you can choose from:
P.S: Choose the goal that will be beneficial for your product in the long run.
Now, as you are clear about your goal, you can start with pre-launch preparation.
We set aside 3-4 months for pre-launch time. We jot down the entire plan and created visuals and content. Everything was done during this time.
Ensure that the product is ready: Who would like to give the new users hard time while they test our product? Nobody, right?
The first thing we checked was that all the features in our product are working fine. We tested it constantly. Also, if there are any bugs, we ensure to fix them on a priority basis.
We also ensure that the website is appealing and has a smooth user interface. Our CTA needs to be visible. Also, everything about the software should already be on the website.
Makers need to be active in the product hunt: Makers = The ones who create the product and launch them on the product hunt.
Ensure that the makers are active and responsive prior 3 months before the launch. By this, we didn’t mean to keep promoting your product. But, you need to try out new products shared on the platform, share feedback and ask questions to the creators.
In short, you need to take part organically in the platform. Ensure that you are not active only for the sole purpose of launching your product. Be deeply involved in this platform.
For us, it has been the most important aspect of our launch time. Our makers were constantly engaging with other creators and sharing their feedback. And in the end, it was all worth it!
Decide the time and date beforehand: The product hunt homepage is set to 24 hours cycle. Hence, deciding the time and date is the crucial aspect of the launch day.
We decided to launch our product on 22nd February, Wednesday at 12:00 AM PST. Let us break it down for you to understand why we choose this particular day and timing.
As mentioned above, we aimed to acquire early adopters to get honest feedback. Tuesday, Wednesday, and Thursday are considered to be the perfect days for the same. Hence, Wednesday it was.
The product hunt homepage refreshes at 12 AM PST every day. So, we decided to make it live at this time. It will ensure that users will get enough time to review and experiment with our product.
Note that, posting after 9 AM PST is a big no-no.
Get your team on the same page: Product hunt launch is a team effort. Ask your team members to be actively engaging on this platform. Let them know how their efforts can contribute to the success of our product.
Make them understand what you are doing and assign the roles accordingly.
Example: Who will be in charge of content planning?
Who will be posting on social media channels?
(This particular part we will be covering in the next section)
We created a slack channel where we discussed everything regarding our product hunt launch. It allowed us to be aligned with everyone on our team. If there are any suggestions from their side, they can discuss them openly in that slack channel.
Have content strategy planned for the next few days: The content strategy plan is the most overlooked yet important part of the launch. Since, the next few days will be quite busy, prepare a content strategy 2 weeks before the launch. We did the same and then assigned roles to the different members of our team.
You need to prepare and post individual content on social media channels. It includes Reddit communities, Discord channels, Facebook and Telegram groups, and many more. Also, make sure that you are not spamming on any of these platforms. As it could harm the product even before its launch.
Create a coming soon page for your product: Schedule your launch on Product Hunt at least 10 days before. It further allows you to create a coming soon page for your product. After this, you can see the CTA of ‘Notify me’ on the page.
Anyone clicking on this will get a notification via email about the launch of your product. Try getting as many followers as you can get before the launch day. So, you are assured about the early upvotes on your product when launched.
Identify hunters of your product: Hunter: The early adopters of the product who can ‘hunt’ the product and show it to the rest of the community.
Having a hunter is not a necessity, but it can bring a lot to your table. Their followers also learn about your product, increasing engagement and visibility.
Kudos to Kevin William David, a well-known hunter who agreed to hunt us on a product hunt. This was another major factor in the success of our product.
If you are looking out for the hunter, check out their previous hunts and pitch your idea to them. You can reach out to them via email or Twitter. Try identifying your hunter at least 10 days before the launch. You can find the hunter for your upcoming launch here.
Besides this, self-hunted products can also be considered.
While major work is already done, here are a few other checklists that also need to be kept in mind.
Set the right positioning of the product: The description is the most important part of your Product Hunt launch. It should be specific and have a clear message about your product.
For the Typo page, we wrote a description that is to the point and short. We answered the two major questions:
Ensuring that it is well-optimized and connected to our unique value proposition. As it resulted in driving organic traffic to our product.
Decide visuals for the profile: Visuals attract a lot of attention. Create appealing images, GIFs, and launch videos to add to your product hunt profile. Make sure they are of high quality and clarity in messaging.
The visuals we created for our page have a minimal design yet clearly describe our product’s features. Our launch video includes all the important information about our product that helps users understand our product in-depth which further, assists their experience.
You can also add image/video screenshots to your page. Also note that, if you are using a GIF image as a thumbnail, it shouldn’t be flashy.
Add PH widget to your website: This will act as an indicator who still haven’t heard of the launch yet. And even for those, who want to learn more about the product.
Keep a check on website traffic: While you have already created a website, it’s important to keep a check on how much traffic it can bear. (Just in case your product goes viral!)
You can keep this day flexible. As the launch day could be your no-sleep day. (Since 24 hours are crucial for your product)
On this day, you can re-check if everything is on track for tomorrow. Don’t keep anything for the last moment.
This is like a 24-hour battle. Here, you are competing with various products that are launching on the same day. Make it worthwhile and for that, you need to be active throughout your day.
Involve every member of your team: Your team is your biggest supporter and cheerleader. Make them your brand evangelists so they promote the product in every way possible. But, also make sure they have explored the platform in advance. So, they know what and how it needs to be done.
You can also assign duties to them in advance so they don’t get lost at the last moment.
Also, don’t forget to let them know that they need to ask for support, not for upvotes. Since product hunt is strict about its guidelines and can report them as spam. (You don’t want to see any of your team members’ efforts go in vain.)
We are a team of 15 members and with our combined efforts, we became the #1 product of the day. If we as a small team, can do so, we assure you can give it a shot too. Trust us, size doesn’t matter. All it matters is your dedication and efforts.
Don’t reach out to your contacts all at once: This is a 24-hour activity. Don’t reach out to everyone altogether. You can divide your outreach into various parts.
For example:
And so on…
You can also ask a few of the team members to upvote early and some of them later. But, make sure that they are members for a decent period before the launch. Since creating new accounts for upvoting on the same day of the launch can again be considered spam.
No fake accounts as well! Since it can lower your upvotes or even avoid your product from being visible on the homepage.
To know your product and competitors’ performance on the product hunt, check out this link: https://pw2.akkio.com/ .
Create buzz on social media platforms: Just like how active you are on the product hunt, the same goes for social media platforms too. You need to let the people know that your product is now live.
A few of the social media channels that we used are:
We posted hourly updates on LinkedIn about how many upvotes we are getting. Either from our product’s page or a team member’s account.
We also posted BTS on our social channels. So that the audience can connect with us.
In Reddit and discord communities, we shared that our product is live. So, that they can support us and give us honest feedback.
In short, you need to make a lot of noise about your product on D-day. But, again make sure that you are not becoming spammy.
Be responsive on product hunt: Makers’ work doesn’t end with releasing their product. You need to respond to every comment and feedback on your product.
Keep interacting with them to learn how you can deliver them an even better experience. As engagement helps to bring visibility and recognition to your product.
Ensure that your answer are insightful & helpful for the users. Also, don’t forget to thank early adopters and hunters for trying out the products.
These responses and feedback can help in prioritizing your product roadmap. And can create a smooth user experience in the upcoming future.
Seek support from other tech startups: We work in a co-working space. Hence, we leveraged it to gain support from other tech startups working there where they shared their honest feedback and opinions about our product.
So if you are too working in a co-working space, it’s the sign.
Create a pre-launch and launch plan on google sheets: It’s not possible to remember everything regarding your product launch. Hence, it is advisable to prepare a detailed plan in advance on google sheets. (Or any other application that suits you well).
We created an in-depth plan that was shared with every team member. It made our product launch easier since everything was in one place.
Your product is now live. But, this is not over yet. You now need to ensure how much users are liking your product and what are the improvements to be done.
In other words, the Post-launch period is all about analyzing your product and making changes accordingly.
Thank everyone who support your launch: We became the #1 product of the day and our happiness seemed no bound. But, it wouldn’t have been possible without people who supported Typo.
The first thing we did after launch day was to express our gratitude to them. We let them know how much we appreciate their support.
And this isn’t about being the top product on the platform. Even if we haven’t been one of them, we still would thank them for their support. Since they took out their time to help us out.
Also, make sure that you personalized your message accordingly. You can also use social media channels to thank your supporters.
Analyze your launch: No matter how well we did on the launch day, the real game begins after it. We checked what really worked for us and what did not. We tracked our Product hunt statistics that includes upvotes, comments, and referrals. How many signups did we get and what do users usually expect from us? We did detailed analyses of our product on the platform.
Not to forget, we also keep a check on our website through google analytics too. We tracked website traffic during and after the product hunt launch, time on site, and bounce rate.
Since you are creating a product for the long run, analyzing every aspect of your product is crucial.
Track user usage: We prepared a questionnaire for tracking the beta users’ feedback. A few of the questions we include were:
We kept the questionnaire short and crisp. And so should you. We also tracked what features are users using, what they are finding difficult, and many more.
Ensure that you are transparent with the users about the tracking process. And also, you act on the insights as early as possible.
Keep promoting your product subtly: Social media channels are a great way to reach out to a wider audience. But, you don’t have to keep promoting your product directly always.
After the product went live, we shared the BTS of launch day – How fun yet challenging it was. We also posted a video thanking our supporters, creating memes around it, and so on.
We just make sure that we aren’t only asking people to try out our product. Rather, educating them, informing them about features, and so on.
We also started our blog section where we inform our target audience regarding engineering metrics, developers’ burnout, engineer managers, and so on.
Ask for support, not upvotes: Although, we have already mentioned it before. But, this is an important reminder for everyone launching on product hunt. Asking for upvotes can lead to more spamming that can trigger your algorithm. As a result, it can drop your product rank or remove it from the homepage entirely.
Ask for feedback, comments, and opinions, and help to spread the word. PH believes people should upvote and comment because they authentically like a product, not because they’re peer pressured into doing so.
New users shouldn’t sign in on launch day: New relevant users in your network should avoid signing in on the same day and upvote only on one product. Ensure that they are already active and engaging with other creators and communities.
Don’t spam on social media: Ensure that you are not spamming on your social media pages as well. This can come across as spammy or manipulation and hurt your product’s credibility.
Get everything planned: Don’t keep everything for the last moment. Jot down important tasks before launch. Also, even if you want to experiment, plan it before d-day.
Avoid bots for upvotes: Never use bots for upvotes. The product hunt platform will automatically remove them which can lower your upvotes.
Create an FAQ section to answer common questions: You can include common questions in the FAQ section. It includes features, pricing, availability, and many more. This will save the time of both makers and users.
If you didn’t become a product of the day, it doesn’t mean your product will not succeed.
Sharing the tips mentioned above may not guarantee you become #1 on the product hunt. It’s about how well you understand your product, audience, and insights.
Also, keep in mind that in the long run, your aim is to reach the target audience.
You can still share your product on social media channels and engage with the community.
Note that what worked out for us may not work for you. So, be flexible about the tips mentioned above and see what is right for you.
It may take a lot of time and effort, but it will be all worth it.
All the best! :)
Sign up now and you’ll be up and running on Typo in just minutes
