DEV Community: Status Hero Editorial Staff

WTF is an OKR!? ft. KPIs or: How I Learned to Stop Worrying and Love the Acronyms

Status Hero Editorial Staff — Tue, 20 Dec 2022 18:27:47 +0000

OKRs are all the rage now so here's a pocket guide on what they are and how to implement them in your team.

Let’s start with a riddle: what do Google, Amazon, The Gates Foundation, and singer/songwriter Bono all have in common? I doubt this will win you any Jeopardy rounds, but the answer is that they all have utilized the OKRs methodology for continued success.

It’s no secret that Silicon Valley has a vernacular all their own, chock full of obscure acronyms. For now, we’ll work on decoding just a few of these.

What are OKRs?

OKRs stands for Objectives and Key Results. Sounds pretty straightforward, right? Setting goals and working to achieve those goals is intrinsic to human nature. But when OKRs are discussed in a workplace setting, there is a specific framework and set of considerations that are being referenced. Some history: originally developed Andy Grove at Intel, the OKR methodology gained enormous traction when legendary venture capitalist and Silicon Valley all-star John Doerr introduced them to the leadership at Google. Once co-founders Larry Page and Sergey Brin quickly recognized their value, a company-wide (at that time, 30ish people) OKR implementation followed.

Okay, okay - we know what the letters stand for, but why were OKRs so revolutionary? What’s wrong with just regular old goals?

Well, OKRs stand out because they put the emphasis on a system of shared objectives. Transparency is prioritized, ideally so the entire company can not only see the OKRs but also contribute to them. Additionally, this goal-setting framework does not require a traditional top-down management approach, which is particularly useful for non-traditional companies and the tech industry.

So, how do come up with successful OKRs that are well suited for your team or organization? To quote a part of Andy’s Grove’s book High Output Management, there are two questions you should always start with:

Where do I want to go? This answer provides the objective.
How will I pace myself to see if I am getting there? This answer provides the milestones, or key results.

To break it down even further: the OKR system is built to train focus, promote team and company alignment, and track goals.

Broadly speaking, Objectives are the what. They should be action-oriented and inspirational. They should also have a deeper level of specificity then just “hire more people for the sales team” or “increase readership every month for this quarter”. There should also be some interrogation as to why you need to hire more people, or what will happen if you increase readership every month?

Key Results are the how. They can include descriptive bullets, and should be specific, time bound, measurable and verifiable. KRs are usually quantitative. Some examples: increase conversion rates by 1%, reach 5,000 subscribers for our newsletter, grow gross revenue to 1 million - you get the idea. It’s fine if you have qualitative KRs as well, as long as there are ways to measure the result.

A good gauge on how well OKRs are working is if you and your team are always referring back to them. It’s both important to make them and reflect back on them. If there are other things consuming your team’s time, you may want to re-think the OKR to recapture that work. Don’t be afraid to redefine OKRs. And if you do end up needing to do this ahead of schedule, dig into what factors are causing the derailment: is it something responding to external factors (ie, a global pandemic), or is some serious backtracking needed? If it’s the latter, your team may want to return to the drawing board and spend some time with Learning OKRs/Learning Goals, where you can focus on testing assumptions, testing the market, and reevaluating. For a deep dive into the three kinds of OKRs, no one explains it better than the folks over at What Matters (a team lead by John Doerr himself).

Another benefit to using OKRs: it can assist with building a healthy company culture. We recently blogged about how important company culture is for remote teams, and the way OKRs can play a role is significant: if you can involve every person at your company or on your team to not only see the company’s vision, but also provide them opportunity to contribute to it, that’s an easy path to increased engagement, higher motivation, and better performance at all levels. A healthy organization should value input from all employees, no matter their title.

As far as timelines go, it’s important to survey your own individual use case. While setting quarterly OKRs is seen as a kind of default cadence, don’t hesitate to change that as you and your org sees fit.

What is a KPI? How is it Different from an OKR?

OKRs and KPIs go hand-in-hand. KPI stands for Key Performance Indicator, and it is widely defined across the Internet as “a quantifiable measure of performance over time for a specific objective.”It’s easy to get lost in the weeds here, because a KPI can start to sound like the same thing as the KR in OKR (ugh with the acronyms already).

So, once again, we will refer back to the team at What Matters, because they sum it up very succinctly: “Most organizations are familiar with KPIs, or Key Performance Indicators. KPIs can be great for measurement, but they’re standalone metrics — they may tell you when a measure is good or bad, but they don’t necessarily communicate context or what direction your team needs to go in. OKRs [...] provide that much needed direction and context. We like to call them ‘KPIs with soul’. The Objective describes what you want to accomplish and the Key Results describe how you know you’re making progress. Since KPIs are measurable, they can make great Key Results. In other words, rather than talking about OKRs versus KPIs, we prefer to think of them as complementary.”

In this letter-heavy world of goal management, the critical thing to not lose sight of is this: you should lead with OKRs and manage with KPIs. OKRs capture more important things to get done, while KPIs are best used for the numbers, details, to-do style tasks, Jira tickets, etc.

Strategy first, OKRs second

Companies love growth. Larger companies translates to more customers, which of course begets more money, more word of mouth chatter, possibly bigger valuations. With this in mind, it’s absolutely crucial for teams and companies to understand the difference between strategy and OKRs. Strategy must come first. The Harvard Business Review has a great take on carving out company strategy: “In a nutshell, [...] mission is about what will be achieved; the value network is about with whom value will be created and captured; strategy is about how resources should be allocated to accomplish the mission in the context of the value network; and vision and incentives is about why people in the organization should feel motivated to perform at a high level. Together, the mission, network, strategy, and vision define the strategic direction for a business. They provide the what, who, how, and why necessary to powerfully align action in complex organizations.”

Only after you have established the core group of tenets for your organization can you begin focusing in on OKR implementation.

“There are going to be times with rapid growth that you focus on just numbers, but in setting strategy, there are a lot of equally important measures before growth. Don’t forget to measure the other KRs needed for a stable and sustainable foundation.” -Ryan Panchadsaram, technical advisor at Kleiner Perkins and former Deputy Chief Technology Officer of the US

What are some Examples of OKRs?

It really depends on the organization.

Since Status Hero is creating and selling a software pro, a lot of our OKRs look something like this:

Objective: Assemble core team, establish processes, and prepare the product for growth.

Key Result: First product team: 2 engineers, 1 design 2. Head of Marketing hired 3. Company OS up and running

Another good practical example: a team that works in Sales. This is a department that runs on numbers, and it makes sense why percentages, projections and goal setting is number-focused. However, if you are already tracking quotas and hard data for your team in another place, you don’t need to use implement OKRs for those same metrics. Instead, take a step back with your team and look at a bigger, more holistic picture — what do we need to get done, what can make us most effective, and how do we measure that? Maybe it’s how many campaigns were sent, how much/how many average customer satisfaction scores went up — the OKR framework should be used as a continual improvement device. Let quota sheets do harder numbers, use OKRs for leading where you want to go as a team.

Tips/Tools for writing OKRs

We’ve found the best way to start is just a blank sheet of paper (well, okay, what we really mean is an empty word processing doc). Everyone can access this document, and company and teams/depts can layer and brainstorm OKRs.

If that sounds too intimidating, templates are available online to help you start the OKR process.

A few reminders to let percolate before you jump in:

The best OKRs are just out of reach — they’re meant to inspire. Chances are good that you won’t hit 100% of your Key Results. That’s completely normal. There is cause for celebration even if you make it to 65% as long as the company and employees are energized and moving in the right direction. We always refer back to this advice from Google: “The sweet spot for OKRs is somewhere in the 60-70% range. Scoring lower may mean the organization is not achieving enough of what it could be. Scoring higher may mean the aspirational goals are not being set high enough. For organizations who are new to OKRs, this tolerance for “failure” to hit the uncomfortable goals is itself uncomfortable.”
One of the reasons OKRs have become ubiquitous particularly in the tech realm is because they allow for aspirational goals, not just “business as usual”. At least one of your Objectives should be what’s considered a “stretch goal” — an aim that’s ambitious, difficult, but still achievable.
OKRs need to align your entire organization toward your most critical objectives. Individual departments and teams shouldn’t have competing priorities. On the flip side, it’s fine if OKRs overlap (and many times they will!) among different departments. Different individuals and team members should take ownership of certain OKRs and KPIs that that encompass the overlay, provided they communicate clearly between said teams/departments.
OKRs are not the same as a To-Do list. A common mistake companies make is turning OKRs into a list of tasks that need to be completed. Your Objectives and Key Results should be about impact, not micromanagement.
Expect a learning curve. It’s unreasonable to expect team members to be an expert at crafting OKRs or even adopting new habits right away. Expect that it will take some time investment for your company to learn and successfully roll out OKRs into your existing workflow. If you are a start up with a small group, the whole org can learn together. At a large company, though, you may want to assign or have specific team volunteer to test out this methodology before adopting throughout the organization. The small team will discover how the system works for them and can distill takeaways and best practices to the rest of the company.
Ideally, you want no more than three to five Objectives at each level of your organization.

If you think you want a guide or template for your first time creating OKRs, the team over at Atlassian has laid out a great three step exercise for this very task.

Building Company Culture for Remote and Hybrid Teams

Status Hero Editorial Staff — Tue, 13 Dec 2022 18:35:22 +0000

If you've got a company, you've got a culture. Investing in your culture for your remote team is just as important as if you all worked in an office. Here's how to improve it.

In any traditional office setting, creating and maintaining a company culture can be a daunting task. Many see it as just another new-agey buzz-phrase that doesn’t directly translate to profit and don’t give it a second thought. The thing a lot of big organizations don’t seem to realize, though, is that culture exists in every space we live in, purposeful or not. If you set out to use productivity and profit as the top indicators of measuring the health of a company, you could absolutely be successful. However, recent data suggests that you may have a hard time hiring (and keeping) new employees. People in all stages of their career are demanding more.

"The biggest myth about company culture is the idea that leaders can think about it later, as if it's something you can decide when you want to decide it.” -Dan Manian, co-founder and CEO of Donut

Increasingly, companies may find themselves struggling with incompatible workplace culture. If your organization is centered around control structures such as seniority-based staffing, durable hierarchy, and tools that only prioritize efficiency, it may flounder when encountering unforeseen issues that require a more agile or entrepreneurial approach. In this scenario, the tipping point is usually prevailing culture: will people stay the course if they feel the company is taking a turn in the wrong direction or doesn’t agree with their personal values, and they have no say in the future?

William Craig hit the nail on the head when trying to define company culture: “How do your employees act when they’re on the job? Are there common behaviors — either good or bad? What does having this job mean to your employees, and would they go elsewhere if they had the chance. These things are not your company’s culture — but they’re definitely symptoms of either a healthy or unhealthy culture. Remember: your company’s culture was already being shaped before you even hired your first employee. So knowing how your employees are reacting to what you’re building is tremendously important if you want your company to thrive.”

As we are a small team of fully remote workers and always looking for ways to improve, these are some great first steps to start to examine culture in your own work environment, and strategies for kicking it up a notch.

Help Teams Feel Valued

If you fall into the “millennial or older” age range, you probably grew up with parents and teachers subtly laying the groundwork for aiming to secure “a good job” after you finish school. Climbing the corporate ladder was the pathway to success. And sure, those opportunities are still coveted, but we would be remiss to ignore the current trends in workplaces. A recent piece from the BBC focuses on studies done this year showing that more and more workers want their job to be less transactional - they want to feel that they make a difference, and they want to believe in the values of the company as well.

Deloitte, the largest professional services network in the world, is now in its 11th year conducting their Global Gen Z and Millennial Survey. The most recent data had similar findings: “Aligning with Gen Zs’ and millennials’ values is also key. Nearly two in five say they have rejected a job or assignment because it did not align with their values. Meanwhile, those who are satisfied with their employers’ societal and environmental impact, and their efforts to create a diverse and inclusive culture, are more likely to want to stay with their employer for more than five years.”

Company culture looks at all different facets of a job — what does the company claim to value, what actions and behaviors are being taken to support those claims, and how does my role in this organization matter. Finding meaning in work goes beyond management simply praising employees for hitting a target or finishing a project early. Job satisfaction and valued work is strongly correlated with employees feeling empowered. Everyone wants a voice at the table, even if it’s to bring attention to a seemingly trivial task, like updating screenshots in a training guide or modifying an outdated Best Practices document. Inviting team members to get involved in decision making is a huge step in the right direction. Other strategies to improve satisfaction: offer rewards beyond compensation, allow for fully remote or hybrid work schedules if possible, realize the need for a healthy work-life balance, plan paths for career growth opportunities, and take a stand on issues that employees are passionate about, like charitable giving, volunteering in the community, diversity and inclusion, etc.

Facilitate Social Interactions

If you asked anyone working on a fully distributed team what the biggest drawback is, they’d probably all come up with a variation of the same response: it’s isolating. Even if you have the cuddliest lap cat or a dog that naps on the anti-fatigue mat at your feet, there’s still something missing - that kind of cultural alchemy that only happens when you’re in a room full of other people. This is where company culture can come into play. Addressing this issue and implementing possible solutions sends an obvious message that your company is invested in a human-centric approach, that your job is something more than just an extraction of labor.

So how do you infuse camaraderie, mentorship, collaboration into a remote workforce environment? One solution could be implementing technology like Donut or Watercooler. These fully integrate into Slack and other communication platforms and use an algorithm to match coworkers together for a shared activity or conversation. It could be an ice-breaker style question that leads to a conversation, matching a new hire with a seasoned team member for a mentor/mentee relationship, or an invitation for two colleagues to schedule a time for coffee or lunch. Interaction types are categorized into Slack channels, and you can join as many as you wish. The focus is strictly helping people enjoy their work and further their career. Per Watercooler’s website: “It is a simple, low ceremony, way of replicating the chance encounters that naturally occur in a physical office. The benefits are immediate: increased well-being and a reduced sense of isolation, improved communication within the team, higher retention of team members and lower chances of burn-out.” Demonstrating intentionality and regard for employee experience goes a long way.

Hybrid teams can also utilize this strategy, though they have the added benefit of face-to-face time that most likely occurs at least once a week, so capitalizing on those in-office days is critical.

Set clear norms for remote teams

Working in a remote environment means most work norms are out the window. If you take time to establish what work days look like for your specific company, department or team, it allows people to easily plan for and predict what their day-to-day will look like. Some items that should be discussed right out of the gate:

Team leads and managers should set clear guidelines about where people can work from and how they will be expected to perform said work. If your team is on a hybrid schedule, be sure to tell team members if they are all needed to come into the office on the same days each week, or if each week will be decided based on workload, time of year, etc. Also address where appropriate virtual workplaces are — is it okay to take Zoom calls while driving or at a coffee shop? Or will your team members be required to do flexible work from a private home office space? Not only will this ensure that expectations are the same across the board, it will also invalidate the perception that individual team members have privileges others don’t. You can do this informally in team meetings and check ins, or draw up a remote work policy that is introduced during onboarding and referenced/updated over time.
Ask team members upfront when they like to take meetings. If your team is particularly distributed, suggest rotating time zones so that certain individuals don’t always get stuck with meeting through meal times or handling end-of-day tasks just because most people have logged off by the time they log on.
Create communication protocols. Clearly define off-hours for things like email and messaging. Lay out expected response times. Be sure every team member contributes to the process of designing the norms. Promote asynchronous communication tools (ahem, did someone say Status Hero) to accommodate remote employees while still encouraging employee engagement. Remote working is all about collaboration — everyone should play an active role.

Outfit Home Offices

Where you work undoubtedly influences how you work. A factor that is often overlooked is having the right setup and training to do your job when you’re not in the confines of an office. Technology needs to be sorted out first and foremost — making sure home Internet speeds are up to snuff, double checking technical specs on laptops and desktops, making sure everyone has headsets and camera capabilities. If team members or new hires are having issues, it may be due to an equity gap, or just a lack of tech savvy. Try to provide everyone an option during the onboarding process to self-select their level of technical skills, always offer IT assistance, and encourage workers to speak with their manager about needing any machine or accessory upgrades if what they already own doesn’t meet the criteria for working remotely.

Beyond these first steps, spend time checking in with your team about their actual work space. Setting up a makeshift home office is going to look different for everyone, and the scale of your org will determine how much of the budget can be set aside for each individual's space. Still, a little can go a long way. Providing everyone with a second monitor, for example, could lead not only to a happier team with a lot less neck and shoulder issues, but also to a big bump in productivity. Looking into standing desks and ergonomic chairs is definitely a huge perk if your company is able. Having a dedicated space that’s comfortable to work in can only benefit, and will most likely lead to high workplace satisfaction overall - it emphasizes that individuals are humans, not just workers, and they should be valued accordingly.

Tips for Structuring a Hybrid Remote Team

Status Hero Editorial Staff — Tue, 06 Dec 2022 19:05:43 +0000

Some companies are fighting remote because they don’t get it yet. Here are some tips to make it easier on you and your team.

We’re closing in on three years since the initial pandemic lockdown. Although the events of 2020 may seem like a distant memory, many companies are still in the throes of remote vs office agony, struggling to get their teams back into a balanced groove. Why the friction? Turns out, people overwhelmingly like working from home. Pushback from higher ups who want a return to “the way things were” often cite productivity as their biggest concern, but there’s new evidence that shows quite the contrary.

A survey by Prudential revealed that “87% of American workers who have been working remotely during the pandemic would prefer to continue working remotely at least one day a week, post-pandemic. Among all workers, 68% say a hybrid workplace model is ideal.

In a working paper that came out this summer, Stanford economist Nicholas Bloom published “How Hybrid Working From Home Works Out”. Findings pertaining to the group of employees who were given a flexible work schedule (three days in office, two at home) were significant: this group reported lower attrition rates, had improved self-reported work satisfaction scores, lines of code written (when applicable) increased by 8%, and employees' self-assessed productivity was up 1.8%.

There are handfuls of other articles and studies, all with the same resounding conclusion: working from home works. So, how do you run a hybrid team successfully? We wanted to share some guidance on how to recapture a productive, cooperative team atmosphere no matter where you’re clocking in.

Create (and stick to) a Game Plan

At its core, Status Hero is team alignment software. It’s useful for accountability, communication and having a real-time log of the work minutia, but arguably its best asset is the ability to see your team in a bigger picture and over the course of weeks, months, years. A huge challenge we see remote teams face is losing sight of the big picture when getting caught up with day-to-day challenges. Scott Dawson, author of “Handbook for the Modern Worker”, starts his tip for the modern worker with sound advice:

Stick to the plan. Reactionary bosses cultivate stressful environments. Be organized. Be visionary. Play the long game. Things go more smoothly if you have a well-publicized plan.

The ability to recenter and refocus a team is perhaps easier said than done, but reframing some periphery issues in the context of a bigger goal makes small things seem, well, small. It also puts you in the headspace to celebrate wins and share well-deserved excitement when your team is getting close to completing a shared goal.

Be Hyper Aware of What Remote is Missing

If your team has elected a hybrid work schedule, take advantage of the days that everyone reports to the office. While remote work has a laundry list of perks, there are of course some trade offs. Fully remote teams have documented areas of work that need special consideration, including: a lack of mentorship and the ease of establishing a mentor/mentee relationship, loss of physical space for workers to collaborate, and developing and maintaining bonds with colleagues. If you are setting up a hybrid work environment, be mindful of what remote space lacks so you can design more purposeful days in the office. This might include:

A seasoned staff member inviting someone newer to the team to collaborate on a project
Staff parties to celebrate newcomers to your team or just to congratulate the team on a job well done once a shared goal has been completed
Access to meeting rooms that are fully equipped with the technology that promotes teamwork and idea sharing
Team building exercises - this one will obviously be dependent on your specific team (but please, no more collegiate ice breakers)

Lead By Example

Revamping your entire company or team’s work schedule is going to require a top down approach. For example, if your company decides to implement a Monday/Wednesday/Thursday in the office, then all higher ups need to abide by the rules that they themselves set in place and make sure they are also in the office during the times agreed upon. This sets the tone that everyone is on the same page.

Bossware, Trust, and “Productivity” Scores

Status Hero Editorial Staff — Wed, 31 Aug 2022 14:01:20 +0000

At Status Hero, we're building the opposite of bossware.

This week, the New York Times published an excellent, terrifying piece called "The Rise of the Worker Productivity Score."

In the article, the reporters describe the increased adoption of employee surveillance software for white-collar jobs that require graduate degrees. (At blue-collar jobs, like roles at UPS or in Amazon warehouses, tracking activity to the minute is ubiquitous.)

Tools like this are commonly referred to as "bossware."

Several disturbing anecdotes punctuate the story, including an instance where a software company continuously tracked developers through their webcams and mouse movements. As a result, employees feared bathroom breaks because the tracking mechanisms were directly (and erroneously) tied to performance assessments and pay.

Proponents of bossware argue that modern workplaces are fraught with distraction. Spying on contributors keeps them on task, they say – Heisenberg was right! But as the story points out several times, the use of bossware has a devastating impact on morale and rewards the dishonest practice of gaming the system. Not only are the resulting "productivity" scores bullshit, but trust among the team and with management are completely vaporized.

That's bad, because high-performing knowledge teams operate on trust. (Don't take my word for it, Google spent 2 years and millions of dollars in research to discover this and share it with us.)

Moreover, knowledge work is about energy management, not time management. As a contributor, high-quality output and collaboration won't happen if you're tired or burned out, no matter how many appointments are on the calendar. Hairy problems often get solved "off the clock" anyways: on a bike ride, in the shower, or standing in line at the grocery store.

At Status Hero we’re building the opposite of bossware: Instead of prying and spying we use brief check-ins and other project management data to enable team leads and organizations to serve their contributors – the people creating value – not the other way around.

For example, with "blocker" reporting in Status Hero, team leads are notified instantly when a contributor is blocked from progress and needs help. We use "mood" emoji to subtly signal state of mind. (We all have both good and bad days that affect our work for personal reasons, do managers need to know the details?) And we're hard at work developing mechanisms to detect burnout patterns. (Think too many GitHub commits late at night.)

So you get all of the data you need and get to keep the trust you’ve worked hard to earn as a conscientious team lead. All of this is within the team alignment framework of collecting a couple of sentences around accomplishments and intentions daily or weekly.

No bossware required.

By Henry Poydar. Henry is the founder of Status Hero. He’s been writing software and leading both co-located and remote software teams for over two decades. He still wants to be an astronaut

What is this thing?

Status Hero Editorial Staff — Thu, 18 Aug 2022 21:33:58 +0000

Turn the engagement level of your team meeting up a notch

I’m always looking for ways to make our regular work more engaging and this usually happens by making it fun. Not “we’re all going to wear silly hats because I told you so” fun, but actual fun for smart minds.

Each week, our team at Status Hero gets together on a video call to run through an agenda that’s likely similar to the one you have with your team. You know the drill:

What happened last week¹
Intentions for this week
Wins from last week
Announcements
Action items

Engagement for these meetings is critical, particularly since we’re all remote. It’s the basis for how we align ourselves for the coming week. It’s easy for this meeting to get boring and routine. Boring and routine are the two main enemies of engagement.

So I made up an exercise called #whatisthisthing, heavily inspired by the popular subreddit. (I didn’t link it up on purpose, you’ll never come back.)

Here’s how it works: at the beginning of our meeting, someone holds up an object from their remote work environment up to the camera. The thing should not be easily identifiable or NSFW. During the course of the meeting, attendees DM the presenter of the thing their guess as to what it is.

At the end of the meeting, the presenter announces the winner. The winner gets a $50 Amazon gift card and becomes the presenter for the next week.

Here’s our new weekly meeting agenda:

Presentation of the #whatisthisthing
What happened last week¹
Intentions for this week
Wins from last week
Announcements
Action items
Results of #whatisthisthing

The results so far? I’ve had fun. The team had fun. We talk and laugh about our things (e.g. espresso dosing rings, vintage motorcycle parts, and a floor desk microphone stand).

I’m not going to pretend that this kind of thing qualifies as a management or leadership strategy, because it doesn’t. That’s hard work you have to think holistically about and do all the time.

But it’s not a gimmick either. Little tactics like this get people interacting on a personal level, and personal relationships are the foundation of trust and collaboration.

Frequency and intensity matter too. People don’t want a giant “team building” exercise foisted on them. #whatisthing for 5 minutes once a week will always beat the “trust falls” at the annual offsite, especially if the rest of the year is buttoned up and all business, all the time.

(For our offsite in October, we’re going to do an IRL expanded episode of #whatisthing, kind of like when your favorite podcast tapes in front of a live audience.)

If you want to give it a try with your team, here’s a Notion template for that, complete with rules.

¹ For the first item, we share a screen with a filtered insights report from Status Hero, which summarizes a week’s check-ins from all team members along with blocker and mood trends. I also use it to prepare for the meeting.

Tweet of the week

The best employees manage themselves. All they need is a shared vision and for you to get out of their way.
— Matthew Kobach (@mkobach) August 4, 2022

Sort of. I’d argue that sharing the vision, getting buy-in on it, and getting out of the way is the real work of management. But he’s very close.

What the algos are feeding me

Vintage computers are fascinating, but I’d argue that the one that put humans on the moon is the most interesting. In this video, a (famous?) YouTube vintage computer dude restores and boots up the Apollo Guidance Computer: https://www.youtube.com/watch?v=g0PIXvjTasI At the ~5:20 mark they turn it on.

And if you want an old but thorough explanation of the problem that this computer solves, here’s an MIT Science Report on the subject from 1965: https://www.youtube.com/watch?v=ndvmFlg1WmE

By Henry Poydar. Henry is the founder of Status Hero. He's been writing software and leading both co-located and remote software teams for over two decades. He still wants to be an astronaut.

Scrum Tools and Best Practices

Status Hero Editorial Staff — Wed, 03 Aug 2022 17:19:00 +0000

Scrum is a simple framework, but it takes deliberate practice and motivation to master it. Learn which tools make it easy to implement with your team.

For any project a team may be working on, there is an associated timeline built around when the project needs to be complete. There has been a lot of development in the past few decades on solutions to properly manage projects and incorporate feedback from users along the way.

According to project-management.com, “Agile project management utilizes an iterative approach that includes frequent and continuous releases, with feedback incorporated throughout.”

The iterative approach is the key element that differentiates agile project management from the traditional “waterfall” project management methodology. With frequent and continuous releases, the agile framework allows the customer/client to review the work at certain points and thus provides opportunities for course correction.

The idea of agile project management came forth after the Agile Manifesto was created in 2001. Seventeen software practitioners came together to uncover a new way to develop software. The following agile methodologies serve as the foundation for agile project management:

This article will focus on some of the best practices and benefits of scrum and explore several tools you can use to aid in its implementation in your organization.

Why Scrum?

In 1999, Dave Snowden developed the Cynefin framework to put certain “domains” into perspective to aid in decision-making. When it comes to software development, there are a lot of unknowns. These unknowns may be due to technological advances, changes in project environments, assumptions related to project requirements, and so on. In the context of the Cynefin framework, software development falls into the “complex” domain.

According to the Scrum Guide 2020, “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

For the teams involved in complex software development, the scrum framework enables value delivery through frequent and continuous releases.

Image concept courtesy of Scrum.org

Benefits of Using Scrum

The scrum framework defines three roles, five events, and three artifacts, each of which will be discussed below. Its pillars of transparency, inspection, and adaptation make the scrum framework uniquely suited to provide the following benefits.

Better Collaboration between Developers and Business Stakeholders

The five events work toward enhancing collaboration between developers and business stakeholders. When these events are implemented as defined in the Scrum Guide, the business stakeholders are made aware of the project’s progress through each of the five events:

Sprint: the event encompassing the other four events, where ideas are turned into value
Sprint Planning: the event in which the sprint commences, where the developers commit for the work to be performed. It addresses the following questions:
- Why is this sprint valuable?
- What can be done in this sprint?
- How will the work get done?
Daily Scrum: the most important event, in which the scrum team meets and reviews the Sprint Goal (one of the scrum artifacts), adapting the Sprint Backlog as necessary
Sprint Review: the event in which the scrum team inspects the outcome of the sprint and determines future work by collaborating with the business stakeholders
Sprint Retrospective: the event in which the scrum team meets to inspect and review their way of working with the various people, processes, and tools involved

Visibility Using Information Radiators

Information radiators provide an at-a-glance view of the latest information about the project.

The Sprint Backlog and Product Backlog provide specific, detailed information about the work remaining to accomplish the project goal (often defined by two of the Scrum artifacts, the Sprint Goal and Product Goal), which should be readily available at any point during the project to ensure transparency.

Clear Accountability

Three roles in scrum—the scrum master, product owner, and developers—are each responsible for various activities, such as business-stakeholder collaboration, development, validation, maintenance, operation, and so on. The accountabilities as specified in the Scrum Guide eliminate confusion and establish a clear understanding of what each role is uniquely responsible for.

Continuous Feedback

The scrum event Sprint Review serves as an opportunity for the scrum team (scrum master, product owner, and developers) and business stakeholders to gather and discuss new information that may have emerged during each time-boxed sprint of two to four weeks. This allows for an iterative sequence of development, review, and feedback that can better help the project achieve its targeted result/goal.

When the Increment (the third of the scrum artifacts) is created as a result of work during the sprint, it becomes the point of discussion for the Sprint Review.

Drawbacks of Scrum

While implementing scrum offers many valuable benefits, it also has a few drawbacks worth noting.

Too Much Flexibility?

Scrum offers a wide range of possibilities for its implementation. Due to the not-so-prescriptive approach of the Scrum Guide, implementation can vary hugely from an organization to another. In the Agile community, it often starts a debate surrounding “Are you really doing scrum?” This can easily turn into an endless quest of discovering better ways of “doing scrum” instead of discovering better ways of accomplishing the work at hand.

The Ambiguous Role of the Scrum Master

The responsibilities of the scrum master as defined in the Scrum Guide are similarly open to interpretation. Sometimes an organization employs a scrum master to do the work of a traditional project manager, while other organizations may want the scrum master to focus on the development work. This ambiguous role can further compound confusion and blurred lines for the entire scrum team as to the actual responsibilities of the scrum master.

Scrum Best Practices

At its core, Scrum is a framework: “an essential supporting structure which other things are built on top of.”

Being a supporting structure, a framework can be adapted according to the needs of the things built on top of it. While this flexibility can become overwhelming, it offers organizations the ability to adapt the scrum framework to meet their unique needs. There is no one solution for implementing the scrum “the right way.” Rather, the scrum framework provides broad guidance on how projects should be carried out, leaving specific applications to be determined by the team.

While these applications may differ from organization to organization, here are some of the best practices from its implementation across the industry that you can incorporate into your use of scrum.

Keep Teams Small, Cross-Functional, and Self-Organizing

Typically, a nimble scrum team is made up of ten or fewer people. Effective lines of communication are key to a project’s success, and as your team grows, this becomes geometrically more complex to manage.

By keeping the scrum team small, you have fewer communication channels internal and external to the scrum team. For larger project implementations with many scrum teams involved, it makes sense to use the Nexus framework to scale the use of scrum.

The benefits of using scrum are further elevated if the scrum teams are cross-functional and self-organizing.

A cross-functional team consists of team members from different functional areas of the organization. Relying upon each other’s knowledge and experience, the scrum team can achieve the goals of the project faster and more efficiently.

A self-organizing team functions without any explicit mandate from authority/top-level individuals. They organize themselves into action. With the necessary empowerment and effective team structuring, teams can maximize the benefits of scrum.

Keep Teams Focused

Unfortunately, even when you have the best processes in place, life happens. Something in production breaks, and it throws out sprint planning. Or an urgent tweak needs to be made in the middle of the sprint. For example, regulations in a country changed, and it is important to ensure that the software is compliant. Typically, this means neglecting the lowest-priority item or having to renegotiate priorities with the different stakeholders.

An alternative approach would be to assign one person each week to only work on any bugs and critical changes if and when they are needed. If your team requires someone to be on standby after hours, it works well to assign these two roles at the same time. If they encounter a problem in the middle of the night, they can implement the fix ASAP during the night and iron out repercussions the next day.

What if there aren’t any bugs or critical changes for them to work on? They can always start working on an item for an upcoming sprint to help reduce the backlog.

Rotating this person out each week not only ensures that no one person gets burned out and that sprint planning remains unimpacted by bugs; the development team also gets exposure to the entire product instead of their focus area.

Follow Scrum Events “by the Book”

The most important aspect of scrum events is their allotted time box. The essence of scrum is in the simplicity with which the events are structured.

For instance, with Daily Scrum, the developers of the scrum team typically meet at the same time and place every working day of the sprint in order to analyze the Sprint Goal and adapt the Sprint Backlog as needed. Utilizing the same time and same place reduces complexity and helps to keep the developers focused on what matters.

When it comes to remote working, the world has rapidly learned to embrace certain tools to better conduct scrum events. The experience of implementing “digital scrum” has been seamless thanks to the wide range of tools available in the market. Here are some of the more popular options currently available:

Jira Software provides an Agile-based approach to run scrum events to drive a scrum project. For instance, in the Sprint Planning meeting, the scrum team discusses the work to be performed for the given sprint. Jira Software facilitates Sprint Planning meetings, allowing for easier ordering of the work items in a sprint.

Image courtesy of Atlassian

Monday also has a sprint planning template that makes it easy to organize the information/work items involved in a sprint.

Image courtesy of Monday.com

Status Hero focuses on keeping your team on track, employing a great check-in feature that allows teams to monitor individual and collaborative progress toward goals. To eliminate additional meetings and better serve teams that are geographically distributed, the Daily Scrum can be conducted virtually and asynchronously using this check-in feature. Once the team members update their daily check-ins, a consolidated summary is made available to report on the status of each team member’s work on the project.

Image courtesy of Status Hero

Manage Product Backlogs Effectively

According to the Scrum Guide, “The Product Backlog is an emergent, ordered list of what is needed to improve the product.”

In the context of a scrum project, a Product Backlog holds the list of features to be developed, as well as bugs and the other security- or infrastructure-related work items. These features, bugs, and work items can be described in the form of User Stories, which detail the work items from the perspective of a user.

While the product owner typically remains accountable for the product backlog, the developers can also provide suggestions for its order and content. In many instances, nondevelopers with less technical insight, whether product owners or clients, don’t understand the impact of completing work in a specific order. Moving a couple of items around could result in less technical depth and potentially even slower overall delivery.

Developers can explain the importance of doing technical work in a certain order by using nontechnical explanations that are easy to understand. The following is an example: “Yes, we know we need to put on shoes so that we can walk through the area with thorns. However, when we need to put socks on after shows, we’re going to have to take the shoes off (taking care to remove some thorns) just to put the socks on and then put the shoes back on. It will be more efficient in the long run if we delay putting our shoes on until we’ve put our socks on.”

Tools like Trello have made it possible to manage product backlogs effectively using product-management templates that help provide better visibility to the feature requests. Trello’s templates also make it possible to more easily facilitate the inward flow of information and feature needs from other teams, such as sales and marketing.

Image courtesy of Trello

Similarly, Airtable can help create a “custom agile workflow,” starting with organizing stories through a backlog. Airtable also offers prebuilt templates, like this one, which includes columns such as Priority, Function, and Sprint, which are flexible and can easily be customized as per the product owner’s needs.

Image courtesy of Airtable

Collaborate on Estimating the Work

When it comes to Agile methodologies, there is a collaborative approach to estimating the work that can be done in a sprint. The scrum team may choose to use story point estimation, which you can learn more about here.

Adding an estimate to a work item happens in the Product Backlog Refinement meeting. Though the product backlog refinement meeting is not a formal scrum event, the Scrum Guide references this meeting to yield more precise work items. Rather than following an estimate provided by just one person (i.e., a manager or technical lead), using story point estimation allows for a collaborative approach that considers the expertise of each of the developers on the team.

Instead of doing estimates by going around the room to ask everyone’s opinion, do planning poker, for which there are many free tools available online. People tend to take their cue from more experienced teammates because of confirmation bias: “My estimate can’t be lower than the most experienced member in the team.” This typically leads to inaccurate estimates.

It’s also important not to simply use the average estimate of the team to speed the process up. If one person scored higher or lower than the rest of the team, discuss that discrepancy. That person might have some insight that the others don’t. Conversely, they might lack some insight, and discussing the estimate will help them grow their knowledge and understanding.

Utilize Team Velocity for Better Forecasts

The Sprint Planning event answers an important question: what can be done in this sprint? In the complex domain of software, it makes sense to answer this question relatively. Scrum teams often use “relative” story points to forecast the work items in the Sprint Backlog.

To best measure their ongoing and upcoming progress, it is important that the team uses a particular metric: After a few sprints, Scrum teams understand their “velocity,” which describes the amount of work they can get done in future sprint(s). In the Sprint Retrospective, Scrum teams can review their velocities and improve forecasting for the future sprints accordingly.

However, understanding the team’s velocity alone isn’t enough. Different people work at different paces, so it’s important to also understand individual velocity. Taking actual sprinting as an example, you assign one story point to running one hundred meters and two story points to running two hundred meters because it is roughly twice the effort involved. According to a user on Quora, the average speed for a male to run a hundred meters is between 15 and 20 seconds. Compare that to Usain Bolt’s world record time of running two hundred meters in 19.19 seconds. It means that the Usain Bolt on your team can complete two story points in the same time that everyone else can complete one.

It is important to know who on your team can do more (or less) work in the sprint than the rest, not for performance management but to take their leave days into consideration. When a high-performing developer plans on taking leave, you need to make sure that you adequately adjust your story points so that the team can handle their work during the upcoming sprint. The same goes if you implement the earlier suggestion to rotate team members to handle bugs or critical issues.

Lastly, keep Parkinson’s law in mind: work expands (and is complicated) to fill the time available for its completion. If a team member keeps on being assigned twenty-one story points per sprint, chances are that it will be all that they can complete. Over time, you need to gradually increase the story points you assign to team members per sprint to prevent them from becoming complacent.

To help you accomplish all these suggestions, Status Hero has integrations and an API to help fetch the estimates and reports from other tools such as Jira, Azure DevOps, and Asana. Using the webhooks, you can populate required data in the activity stream. You can check out Jira integration as an example here.

Conclusion

Scrum is a simple framework, but it takes deliberate practice and motivation to master it. In this article, you learned about the nuances of the scrum framework and examined some tools that can aid in its successful implementation.

As the hybrid/remote way of working continues to become increasingly popular, the importance of asynchronous communication has become crucial, especially for teams implementing scrum. If you are an agile coach, scrum master, or a scrum team member, consider using Status Hero to help synchronize and connect your team without the hassle of scheduled meetings or other interruptions.

By Aditya Kulkarni. Having a development background, Aditya chose to pursue the path of being a Scrum Master and Agile Coach, and he's recently jumped back into the world of writing.

Using Kanban in Software Development

Status Hero Editorial Staff — Wed, 27 Jul 2022 16:01:09 +0000

If you’re looking to get started with applying a project management methodology to your workflow, Kanban might be just what you need. It’s relatively easy to get started with and the core practices can be applied one at a time as your team needs them, making it a great option for teams hoping to provide a bit more structure to their project management.

When you’re developing a piece of software, it’s essential to manage the overall project well to ensure that all the members of your team are on the same page and that the project keeps moving forward. Traditionally, project management has taken what is known as a waterfall approach. This means that work flows from one phase to another, with any changes requiring a restart of this flow. However, in recent years, an “agile” approach to project management has become much more popular. In contrast to the waterfall model, agile project management is “an iterative approach to managing software development projects that focuses on continuous releases and incorporating customer feedback with every iteration.”

Under the umbrella of agile project management, a few methodologies have taken shape:

Scrum is a methodology where an individual called a Scrum master manages the flow of work, dividing it into sprints of consistent units of work to be completed by the Scrum team. After each sprint, the previous sprint is evaluated, and learnings are taken into account to adjust for the next sprint.
Kanban is a methodology that focuses on visualizing the flow of work, managing this flow, and helping the entire team work together while limiting the amount of work in progress to ensure everyone is working efficiently. This is the methodology that will receive the focus of this article.
Extreme Programming (XP) is a methodology that focuses most specifically on the development practices of the team completing the work. XP is best suited for small, co-located development teams where the technology being used allows for automated testing.

In this article, you’ll learn more about the Kanban methodology and see how it can help your team manage the software development lifecycle more efficiently.

What Is Kanban?

The Kanban methodology was first developed and used on a large scale in the 1940s when the Japanese car maker Toyota started using it to track and manage their workflow. By assigning tasks and products that were in progress to cards and only allowing team members to perform work that was attached to the cards in front of them, the Kanban system helped them to make their workflow more efficient and ensure that less time and materials were wasted throughout the entire manufacturing process.

Image courtesy of Atlassian

It wasn’t until the early 2000s, with the rise of Agile programming, that the Kanban method began to be used in the software development world. Because the Kanban methodology focuses on the flow of work through a system, the same principles that made it useful in manufacturing can be transferred over to a software development process as well. Some of the core Kanban practices—visualizing the flow of work, limiting the amount of work in progress, and implementing feedback loops, among others—are particularly useful in software development. Because of this, software teams around the world began adopting Kanban as a methodology for running their projects, and it is still widely popular today.

Kanban operates on four principles: (1) start with what you do now; (2) agree to go after incremental change; (3) respect the current process; and (4) encourage acts of leadership at all levels of the organization. These four principles make Kanban an approachable process that allows teams to get started right away and scale up gradually over time, with input from the entire team.

In contrast to many other agile programming methodologies, some teams find Kanban easier to get started with while still being able to realize some of the same benefits around process management. Kanban focuses on the speed of delivery of work and of delivering tasks as soon as they’re completed rather than waiting for the conclusion of a sprint. Also, because the focus is always on the next highest priority card, streams of work can be reprioritized in real-time while still allowing all the various stakeholders and team members to view the current progress and status of work at a glance. However, some teams like and need the more rigid process of some of the other methodologies. For example, engineering-focused teams might benefit more from the principles of XP, especially if they need more guidance on the engineering side of things.

Many teams have found that the principles of Kanban give them all the benefits of having a structured methodology while making it easy to get started, even if they haven’t used a particular system of project management before. Let’s take a closer look at what Kanban is all about.

The Core Practices of Kanban

As with most systems, Kanban is defined by a set of core practices that help teams structure their workflow:

Visualize the Flow of Work

One of the most important principles of Kanban revolves around visualizing the flow of work. In teams without a project management system or plan, it’s oftentimes not clear how the work flows. And when the flow of work is unclear, it can be equally unclear where bottlenecks are happening or how the process could be made more efficient.

However, with Kanban, the process starts with visualization. The cards representing each piece of work can be moved from one stage to another. This is crucial to the process because it allows everyone on the team to know the current status of the work, as opposed to this knowledge being stuck only inside the head of the person completing the work.

This initial step of determining how work flows through a system can yield insights into potential efficiencies even without implementing all the other practices of Kanban that will be discussed below. Because visualizing the flow of work in a previously opaque system can bring such impressive productivity gains, it’s an important practice to implement first. Sometimes these cards are divided into swimlanes—horizontal lanes on your board that help you to subdivide relevant groupings of work even further. Additionally, color-coding cards or applying labels allows everyone to be able to quickly see how work is grouped together.

Limit WIP (Work in Progress)

One of the bottlenecks of many existing project management systems is that each member of the team has a ton of work that’s considered “in progress.” Because of this, team members are constantly jumping back and forth between tasks and not dedicating enough focus to any particular task. This essentially ensures that there’s always chaos and misunderstanding surrounding what work is currently getting done. It also makes it difficult to plan for future availability and the completion of future work. However, by limiting the number of tasks that can be considered in progress at any given time, the Kanban system ensures that work flows smoothly through the system at all times and ensures that all team members are on the same page about current priorities.

Image courtesy of Mircosoft

A good rule of thumb for this is to make sure that any given team member has no more than two items in progress at any one time. For example, if you have five team members, you should have no more than ten items in progress at a time. If this means a team member ends up with extra bandwidth because of this restriction, they have the freedom to help other team members with tasks they might be stuck on. By limiting the WIP and reallocating extra bandwidth to help on some of the other in-progress tasks, you ensure that the most important work gets completed first.

Manage Flow

Once the first two practices have been accomplished, it’s important that you continue to manage the flow of work. This could mean anything from modifying the steps in your workflow to make it more efficient to changing your work-in-progress limits given the size and speed of the team. It could also mean using your new system to identify bottlenecks and finding a way to improve them. Specific applications will vary, but the goal of this principle is that the Kanban system you’ve put in place continues to get better as you execute on it.

For example, you might notice that even once you’ve set up your flow, tasks still aren’t moving through the system fast enough—you might still have too much work in progress. Experimenting with lowering your work-in-progress limit to see if it can focus the team and start to help work flow faster could be a good first step to take.

Make Process Policies Explicit

Once the process is defined, it’s important to make the policies around the process explicit. Without explicit policies, even the most well-defined system can fall into disarray over time. To ensure that everyone on the team is on the same page, you’ll want to clearly specify things like how bugs are prioritized against existing planned work, who can move cards throughout the process, how work gets assigned, and so on.

Implement Feedback Loops

Feedback loops are very important to the Kanban methodology, both in terms of evaluating the work that you’re doing as well as evaluating the Kanban process itself. Getting feedback on completed work ensures that future work that moves through the system will be even better and more efficient.

Feedback loops, for example, might involve a regular retrospective with the team. This would surface questions regarding how everyone feels the day-to-day work is going, whether they feel the process is too burdensome, and most importantly, if they can (and should) include input from end-users or the customer support team. Feedback loops are critical in determining whether the process is really working, especially if there’s work that is being recycled through the system because it doesn’t meet a quality standard or doesn’t work well. All the process efficiency in the world doesn’t matter if the work output is not up to standard, and if that’s the case, adjustments need to be made.

Improve Collaboratively, Evolve Experimentally

Because everyone on the team will have a different perspective on the process, it’s important to make improvements collaboratively. Even though Kanban doesn’t have scheduled retrospectives like Scrum or other methodologies, it’s still important to evaluate how the process is working as a group and take everyone’s suggestions as to how the process might be improved.

Then, as suggestions are made, consider evolving the process according to these suggestions experimentally—give a potential improvement a try and see if it actually does improve the process or the flow of work over a given time period. If it does, update your process policies to reflect this change.

Wrapping Up

If you’re just looking to get started with using a project management system or applying a project management methodology to your workflow, Kanban software development might be just what you need. It’s relatively easy to get started with, and the core practices can be applied one at a time as your team needs them, making it a great option for teams hoping to provide a bit more structure to their project management.

To make Kanban work within your organization, communication is crucial. Making sure your team is on the same page through every step of the process is the best way to ensure that it works for you. Using a tool like Status Hero can help you to keep track of who is working on what and replace lengthy meetings with succinct online updates, allowing you to implement the Kanban process faster and even more efficiently within your team—especially if your team is remote.

With tons of integrations with other tools your team is already using, Status Hero is the easiest way to make sure your team is on the same page, especially when implementing something new like Kanban in software development.

Status Hero, paired with a software development methodology like Kanban, will completely change the way your team builds software, and you’ll wonder how you ever did it any other way.

By Keanan Koppenhaver. Keanan is the CTO at Alpha Particle where he helps publishers modernize their technology platforms and build their developer teams.

Understanding the Agile Triangle’s Role in Product Development

Status Hero Editorial Staff — Wed, 22 Jun 2022 13:20:55 +0000

Learn how the agile triangle helps teams better manage the quality, value, and constraints of their projects.

For many years, the iron triangle has been used by project managers to coordinate and ensure the quality delivery of products by focusing on cost, scope, and schedule. However, with the rapid changes in technology in the modern age, the iron triangle has failed in product development due to its lack of consideration of other relevant factors such as quality, value, risk, dependencies, and obstacles. Because of this, many companies now use the "agile triangle” instead.

The agile triangle of product development focuses on delivering products of high quality using a simple work process while accommodating the rapid changes of the technological world. Where the iron triangle emphasizes cost, scope, and schedule, the agile triangle takes a broader focus on quality (intrinsic quality), value (extrinsic quality), and constraints (cost, scope, and schedule). Here, while constraints are still a factor in measuring the success of a project, they are not the defining goal.

There is a divergence in these two methods of product development in terms of their fundamental assumptions, as well as the organizational structure, management style, roles, and responsibilities typically associated with each. These differences have become a major challenge in product development. For instance, an agile team can be working to meet certain goals, while managers are measuring their performance using a different set of objectives.

Jim Highsmith, pioneer of the agile triangle, stated, “Many agile teams are now caught in a dilemma. On one hand, they are told to be agile, flexible, and adaptable, but on the other, they are told to conform to the pre-planned traditional iron triangle framework of scope, schedule, and cost.”

In this article, you’ll learn more about the iron and agile triangles, with a specific emphasis on the role of the agile triangle in the world of product development.

The Iron Triangle

In every project management class, one of the first things students learn is the iron triangle, which teaches that a project’s cost, scope, and time are interdependent. These constraints have been the heart of measuring success in project management for decades.

Cost

Cost refers to the budget allocated to a project. It includes financial resources as well as the manpower required (in software development) to deliver a product within a prearranged scope. If a project’s budget decreases, the scope of the project will also decrease, as some features will be removed or adjusted so that the project can be accommodated within the new cost. Furthermore, the timeline in which the product is to be delivered will increase due to the financial restraints upon the available labor force. Naturally, this may also impact product quality.

Scope

The scope of a project describes the boundaries that a project must deliver upon. It covers all the planned features to be implemented, as well as the processes required to implement those features.

Scope may refer to either the scope of the project or the scope of the product. Product scope covers the features and functionalities of the product itself, while project scope covers the process required to deliver the product with the specified features and functionalities.

Scope has a direct effect on the cost, schedule, and quality of a product. If the scope of the project goes up, the resources required to deliver such a product will follow, also driving costs up. For example, in software development, if more features are to be added to a project, the resources required to hire a developer with the required skill set will increase, as well as the time required to add these features.

Schedule

A project manager’s numerous responsibilities include the all-important duty of ensuring that a product is completed within the stipulated time frame. Answering questions like “Is the product ready for launch?” or “When will it be ready?” is key to their role.

As you’ve seen, changing any of the constraints in an iron triangle project will have a significant impact on the other constraints. For example, if you alter the timeline of a project by limiting it, then the scope of the project will probably decrease, and employees will need to work overtime to meet the new deadline. This often results in worn-out team members and may ultimately affect the quality of the product. The cost of the project will also be impacted, as you may need to increase the number of people and resources required to finish it.

Product Quality

In the middle of the iron triangle is quality. All the aforementioned constraints contribute to the overall quality of a product in an interrelated fashion.

If the cost of a project is minimal, the quality of such a product will be affected greatly due to scarce resources. If the time for a project is limited, some features may have to be removed from the scope, and the labor force will be limited, meaning that employees may need to work extra time within the provided budget, which often results in burnout and/or a poor product. Finally, if the project has a large scope, the product will have more features and functionalities; however, this will translate to higher costs and increase the time required to deliver the product.

Limitations of the Iron Triangle

Despite the iron triangle’s long-standing use, it has some limitations. For instance, a project of good quality can be completed within the stipulated budget and time but can still fail to meet the customer’s satisfaction or result in employee burnout. A project otherwise on track may also be derailed by new government regulations, industry standards, or stakeholders’ demands, thus altering its progression.

To overcome these limitations, a new methodology for product development was developed to measure the success of a project from a broader perspective that takes customer satisfaction and a variety of other factors into account.

The Agile Triangle

With the rapid wave of innovations characteristic of the world of technology, a number of industries and projects have shifted to a new framework that better allows them to respond to client feedback and the ever-evolving changes in product requirements, regulations, and industry standards.

The agile triangle focuses on quality (intrinsic quality), value (extrinsic quality), and constraints (cost, scope, and schedule) as a measure for product development. Designed based on the Agile methodology, it considers these three factors while also emphasizing collaboration between project stakeholders and focusing on the business value of the product.

Quality

The quality of an agile project involves reliability, continuous delivery of value to customers, and product adaptability. With the agile triangle, the success of a project is measured not in terms of scope, schedule, and cost alone but also in terms of how reliable the product is, the product’s ability to adapt to new regulations, and changes in customers’ desires.

Value

Under the agile triangle, value refers to what the project stakeholders expect and want from the project, with a focus on delivering a releasable and usable product. The agile triangle uses feedback as one of its tools to measure the success of a project and to improve future releases. Although measuring the success of a project using quality and value is not an easy task, it gives you the best insight to evaluate the success of your product.

Constraints

These are the traditional scope, schedule, and cost found in the iron triangle. The agile triangle prioritizes releasing value and quality to users, while constraints are used to help define project timelines and schedules. Jim Highsight suggested that “value and quality are the goals and constraints may be adjusted as the project moves forward to increase value.”

Collaboration

Collaboration is vital in any agile project because it ensures that all project stakeholders are updated with the project’s progress and that the development team is informed about new requirements. Stakeholders collaborate with the development team to ensure that the product is on the right track, the product-development team interacts with users/owners who provide feedback about the product, and lastly, the development team collaborates with one another to address any challenges a team member may be facing.

Focus on Business Value

One of the fundamental principles of the agile manifesto is that the “highest priority is to satisfy the customer.” To ensure that your organization abides by this principle, product owners must clearly define what the desired business outcome is and constantly communicate the new requirements to the development team. Also, as the Agile methodology focuses on customers and product users, it is important to obtain feedback from customers and make changes accordingly, reassessing the product using a feedback loop at each iteration.

The Agile Triangle’s Role in Product Development

As you’ve seen, the iron triangle is built upon the triple constraints of time, cost, and scope, and a change in any of these constraints will force a change in at least one of the others. Under this methodology, the scope is typically fixed at the start of a project, while time and cost can be adjusted to meet an acceptable plan. However, during a project’s lifecycle, the scope can change due to emerging technology, new regulations, change in customers’ taste or desires, and so on.

At the beginning of a software project, you may outline your project scope to cover all the features you want, while new government regulations may later require you to adjust the scope to capture this regulation. This can translate into an increased cost to hire the labor force required to implement these new changes and also an increased project time, ultimately resulting in cost overrun and late product delivery.

The agile triangle uses a different approach. It sets time (iterations) and cost (team members) as fixed pieces, while the scope remains variable to adapt and evolve to changing expectations over time. This provides plenty of room for new customer feedback, new government regulations, and emerging industry standards to be captured within the budgeted cost and time. Essentially, the agile triangle allows the scope to vary because you cannot know everything about the project at its inception; your scope will continue to change as you learn more about the project.

How Constraints (Cost, Scope, and Schedule) Impact the Value and Quality of the Product

Naturally, the scope of your project plays an important role in the value you deliver to your stakeholders. The agile triangle allows you to start with a tiny scope and increment after every iteration until you run out of time and budget (cost). By doing so, you deliver a working product at the end of each interaction. Here, value is the ultimate goal, and the project constraints may need to change as the project progresses in order for you to increase product value. You can make your schedule (iterations) fixed but may continually adjust the scope to deliver the highest value.

One of the multibillion dollar companies to have successfully used this methodology is Motorola. Using its MOTOTRBO Nitro program as an experiment, the development team was reorganized, new team members were hired and trained based on the Agile methodology, and all traditional bottlenecks were cleared. During this experiment, Motorola observed that in the traditional iron triangle method, development teams were consumed with processes (schedule) such as regimented product-release timelines and paid less attention to the value of the project.

However, Motorola found greater success using the agile triangle. John Kedzierski, a senior vice president of video security solutions at Motorola, said that they “adopted leading practices and gleaned a number of important lessons along the way.” Some of these lessons, as extracted from a Wall Street Journal publication about the experiment, included the following findings:

It is easier to implement such changes in methodology with a new program, as new programs don’t have revenues, expectations, or customer preferences already associated with them.
While teams can have the desire to change from time-consuming legacy processes, many find it challenging to do so even when given permission.
The agile triangle methodology requires constant communication, as well as less focus on what the organization is going to do—such as a product launch on a certain date—and more attention on development, testing, and upgrades, thus adding more value to the product.
Better products are created when the developers writing the code and designing the hardware are involved in the decision-making process.

These findings demonstrate that the team was able to better focus on creating products that deliver value to customers by cutting down on time spent in legacy processes. With developers being part of the decision-making process, proper technical attention was given to the scope of the project, ultimately leading to the development of better products and increased customer value.

Conclusion

One of the early tools used for product development is the iron triangle, which focuses on cost, scope, and schedule to measure the success of a project. However, this method has failed in product development over time, causing project managers, organizations, and researchers to look for a better alternative. This gave birth to the agile triangle, which instead emphasizes quality, value, and constraints to measure the success of a project.

In this article, you learned about the iron triangle and its limitations, as well as the agile triangle and its role in product development. By using the right tools and measurements, your development team can deliver quality and valuable products that meet customer expectations and save on cost.

Be sure to check out Status Hero, an agile management tool that can help your team work more effectively. Status Hero enables you to replace the time-consuming meetings typical of traditional project management with efficient and insightful reports that allow you to gather a clear understanding of accomplishments and blockers across your organization. To learn more, sign up for a free trial or take a tour today.

By Rabo James Bature. Rabo is a postgraduate student at the University of Jos and the co-founder of hiyaar.com. He spends most of his time studying current cybersecurity threats while teaching organizations and individuals how to better secure devices and networks.

Agile Engineering Best Practices

Status Hero Editorial Staff — Wed, 15 Jun 2022 14:36:29 +0000

Agile engineering preaches being efficient and responsive to change in order to develop the best product. Learn its best practices and how they can enable you to create a rapid, continuous development cycle.

In just about any modern tech startup or enterprise company, software development teams adopt what’s known as an agile engineering process. In agile engineering, teams constantly develop and iterate on prototypes in response to a steady stream of customer feedback and demands. This contrasts with the more traditional approach of predicting customer preferences and developing a single prototype to try and address them all.

The agile approach is a must in a fast-paced industry like software engineering, but it can be applied to many other fields as well. Agile teams are able to quickly make decisions and develop features that give the greatest customer satisfaction. They also take on less risk with each decision: because the feedback loop occurs so frequently, agile teams can easily pivot to a different decision if they receive a negative response from customers.

Overall, teams that adopt an agile mindset save more time and money in the long run. This article will list all of the most essential agile engineering best practices that your teams must implement in order to maximize efficiency in today’s ever-evolving tech industry.

The Agile Manifesto

Tenets outlined in the Agile Manifesto inspire modern agile engineering processes. Briefly, here are the four tenets.

Individuals and Interactions over Processes and Tools

While processes and tools are necessary, they can’t by themselves determine customer needs. In some cases, strict adherence to processes and tools may also delay the development process. By placing a higher value on individuals and interactions, engineering teams put themselves in a better position to respond efficiently to business needs.

Working Software over Comprehensive Documentation

“Comprehensive documentation” refers to anything used to keep track of the development process, such as technical specifications and testing plans. While agile engineering does attribute some importance to project documentation, it should never get in the way of the ultimate goal: to produce working software.

Customer Collaboration over Contract Negotiation

Your customers play a big role in agile development. In many ways, your customers are your biggest stakeholders. As such, it’s paramount for engineers and product managers to collaborate with customers on details such as technical requirements and feature requests.

Responding to Change over Following a Plan

Agile engineering got its name from the word “agile,” which Merriam-Webster defines as “marked by ready ability to move with quick easy grace.” Change is inevitable in business. Agile engineering teams are expected to embrace change and respond accordingly, rather than stick stubbornly to a plan.

Best Practices

Based on these four tenets, agile engineering teams have created and fine-tuned various practices that have become commonplace in most tech companies. A specific type of agile methodology known as scrum comprises four best practices that all teams adopt.

Sprint Planning

A sprint is one of the most basic building blocks in the agile philosophy. Sprints are defined by a set amount of time and a set number of tasks. During the sprint, scrum teams work to complete each task before the sprint ends. Each team defines its own sprint length, but sprints typically last from two to four weeks.

Sprints usually begin with a sprint planning meeting. During sprint planning, tasks for the sprint are chosen, sized, and then assigned to individuals. Each sprint planning meeting involves the following cast:

Product managers (or in some cases software managers) are responsible for choosing tasks for the sprint from the project backlog. As they are the primary liaison between the customer and the engineering team, they have the best knowledge of various business priorities and choose tasks accordingly.
Software engineers work together to estimate the effort required for each task. They distribute the work evenly among the team.
The scrum master facilitates the sprint planning meeting. The scrum master may be the product manager, software manager, program manager, or a software engineer.

In a good sprint planning meeting, the team emerges with a clear understanding of the sprint objectives, as well as the items they are tasked with. These items are usually organized into a sprint board (or scrum board) for status tracking.

Job Sizing and Estimation Techniques

In order to plan a successful sprint, backlog tasks must be sized appropriately. Underestimating tasks can have negative cascading effects on future sprints, which ultimately delays project delivery. This can also hurt team morale.

Agile engineering teams have come up with several estimation techniques for sizing a task.

Story Points or Task Points

Teams can define a story point in any manner they like. On some teams, a story point loosely translates to a day of work; other teams may define it as half a day of work or even an hour.

In an ideal sprint, every engineer has enough story points for the entire sprint. For example, for a two-week sprint, where one story point equals one hour of work, each engineer should be assigned eighty points of work.

As the team undergoes multiple sprints, they may refine their definition of a story point. For example, suppose a team consistently underestimates the effort required for tasks. If their previous definition of a story was one hour, they might redefine it to be two hours instead. In this case, each engineer would then be assigned forty points of work per two-week sprint.

Fibonacci Estimation

Teams that use story points often use the Fibonacci estimation technique. Rather than use any arbitrary number to size a task, teams use numbers from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, and so on). The Fibonacci numbers are adequately spaced from each other and provide a good proxy for story points for tasks of varying complexity. This can help provide more realistic estimates, especially for larger tasks.

T-Shirt Sizes

A somewhat more abstract way to estimate tasks is by using T-shirt sizes (XS, S, M, L, XL). As with story points, teams can define each T-shirt size as they like and refine this definition over time. For example, an XL T-shirt-sized task might take up the entirety of a two-week sprint, while an XS T-shirt-sized task might take half a day or less.

Planning Poker

No matter the estimation technique, teams should also consider using scrum planning poker to size their tasks. In planning poker, each attendee offers their own estimate for a task and reveals this estimate at the same time to all other attendees. This makes the estimation process collaborative and ensures that one person’s estimate doesn’t overshadow anyone else’s.

Daily Stand-ups

Throughout a sprint, teams will hold a daily stand-up (also known as a daily scrum). Stand-up is a short meeting, usually no longer than fifteen minutes, that occurs every day at the same time. Its primary purposes are to keep everyone up to date on the status of the sprint and to identify any current blockers.

During stand-up, teams usually stand in a circle. The scrum board is displayed for everyone to see. Each developer gives a quick status update on their sprint items, focusing on the following three points:

What I worked on yesterday.
What I’m going to work on today.
What issues, if any, are currently blocking me.

As developers give their updates, they may move their items on the sprint board across different progress stages (input queue, in progress, testing, in review, pending, complete). In addition, stand-up updates should be quick and to the point. If there are topics that need additional discussion, developers can huddle after everyone has given their updates.

Retrospectives

At the end of a sprint, agile teams will hold a retrospective. In this meeting, the team reviews the sprint and discusses the following:

What went well? Always include positives in a sprint retrospective. Each member should get a chance to share what they thought went well during the sprint, and commend other team members when appropriate.
What obstacles arose? Sprints don’t always go smoothly! Sometimes, tasks take much longer than anticipated to complete, and some need to be punted to the next sprint altogether. It’s important to identify any risks or blockers that caused this to happen. Doing so immediately after a sprint can help determine whether project timelines are still realistic.
What can we improve in the next sprint? This is perhaps the most important question. In order to set up future sprints for success, everyone should share practical ways to improve the team’s processes and the project as a whole.

To better facilitate discussion, scrum teams like to use sticky notes along with a whiteboard (or virtual board). The whiteboard is divided into three sections, where each section is dedicated to one question above. The group then spends the first ten minutes of the retrospective filling out sticky notes and placing them in the appropriate section. This gives everyone an equal chance to get ideas on the board.

After discussing each sticky note, teams usually vote on the best ones. This helps define concrete action items to commit to for the next sprint.

Conclusion

Agile engineering is a term that is used often in the software industry, and for good reason. It’s a philosophy that preaches being efficient and responsive to change in an effort to develop the best product that suits customer needs.

From this philosophy arose the scrum methodology. This article introduced four best practices that all scrum teams implement—sprint planning, job sizing, daily stand-ups, and retrospectives. Together, these best practices create a rapid, continuous development cycle that’s necessary in an industry like software engineering.

Status Hero is a tool that supports the agile methodology by changing the way teams approach daily stand-ups and other meetings. Status Hero uses periodic prompts and data from project management tools like Jira and Asana to automate generation of team-wide status reports. This can help your team eliminate time-consuming meetings to focus on more important issues instead.

By Alexander Yu. Alexander is a technical writer at AWS by day and a freelance writer by night. After completing his BS in electrical engineering and computer science from UC Berkeley, he became a software developer at AWS for almost three years before transitioning into technical writing. He lives in Seattle with his dog Yuna.

Engineering Estimates

Status Hero Editorial Staff — Wed, 08 Jun 2022 13:19:33 +0000

Learn about story point estimation, the problems it solves compared to time-based estimation, and how best to implement it with your team.

Estimating engineering work is a very complex task. Most teams find it hard to accurately estimate development effort as there are a lot of things that need to be factored in. For example, a senior developer might complete a task in two days, while a junior or intermediate developer might need four to ten days for the same task. Further, if a senior developer is busy with meetings or waiting for third-party integrations, a task that would normally take two days might easily require four. Estimates are such a contentious topic that some agile leaders and coaches, proponents of the #NoEstimates Movement, advocate for abandoning them entirely.

Engineering work is traditionally estimated by looking at the time required to complete a task. However, this method does not consider the task’s wider context—for example, varying team skill levels, unscheduled meetings, unclear requirements, waiting on integrations, changing objectives, and so on. As a result, time estimation leads to an increased risk of missed deadlines, task bottlenecks, and scope creep.

Story point estimation, on the other hand, is an estimation technique that instead looks at the effort required. In story point estimation, instead of time, each user story (work item) is assigned a number (points) representing the effort required to complete it. The actual time required to complete the user story is not known during estimation; this makes it easier to deal with complexities, risks, and unknowns that might arise.

In this article, you will learn about story point estimation, the problems it solves compared to time-based estimation, and how best to implement it with your team.

Benefits of Story Points

Story point estimation is a holistic approach to task estimation. Rather than focusing on the time taken, which might differ from developer to developer, story points look at the effort required to complete a particular task. With story points, the team assigns points to a backlog item relative to the required effort, its complexity, and any risks or uncertainties.

This approach has the following benefits:

More easily identify the required effort: Since point estimates are independent of the time it takes to complete a task, team members can more easily agree on the effort required for a particular sprint item.
Accommodates different skill levels in your team: Unlike time estimates, story points show a clear measure of the effort required for a particular task, making it easier to assign resources to tasks. Senior developers can take on higher-point tasks, while junior developers take lower-point tasks.
Helps measure the team’s sprint velocity: A team’s sprint velocity measures how much work a team can accomplish during a single sprint. This is useful when assigning work to complete during a particular sprint and also for gauging team productivity. By using story points, you can easily calculate your team’s average velocity by looking at the total number of story points they complete each sprint. The more points your team can complete without becoming burned out, the more productive they are.
Build consensus and eliminate gray areas: When using story points, a whole team has to agree on estimates, which helps to ensure requirements are properly understood and eliminate incomplete information. This agreement is achieved through a process known as planning poker, which is explained later in the article.
It’s a faster way of estimating work: Story point estimation reduces the time taken to estimate work. This is because this estimation technique assigns points to a work item relative to other work items, so as you complete more tasks, it becomes faster and easier to estimate the effort required for new tasks.

While story points can simplify and improve the estimation of tasks, some critics have highlighted the following drawbacks:

Difficult transition: Transitioning to story point estimation might be hard for teams that are used to estimating tasks using time (i.e., hours, days, and weeks).
Need to account for time spent: Ultimately, story point value needs to be converted to time for project-planning purposes, which is sometimes challenging. Project managers have to use sprint velocity to estimate time spent per story point.
No standardization: Story points are not standardized—there is no set value for one story point, and the values may differ from team to team. This means that story point baselines and estimations are different in each team, making it difficult to compare velocities between different teams.

Understanding Story Points

To properly estimate a given task using story points, the team will review the task and assign it a story point based on three factors:

Effort: This is how much work will be required to complete the task. This effort is independent of a developer’s skill level or experience. Instead, a team establishes a baseline—for instance, adding a button is one story point, and then subsequent tasks are assigned points relative to that task.
Complexity: This is how complex the given task is. The task will be assigned more points depending on how complex it is or how many dependencies or integrations it has.
Unknowns: A key hallmark of agile is being adaptable enough to work with changing requirements. This means sometimes you have to estimate work before all the requirements are clear. Story point estimation takes this into account and assigns more points to tasks with more uncertainties.

Story Point Estimation with Fibonacci Numbers

Story points are a relative estimation tool—they estimate work relative to other work items. To achieve this, story points use the Fibonacci sequence to assign points. This means that when assigning points, we do not assign any linear number but instead use numbers from the Fibonacci sequence. The Fibonacci sequence is a mathematical number sequence developed by Leonardo Bonacci, where each new number is the sum of the two previous numbers—that is, 0, 1, 1, 2, 3, 5, 8, 13, 21, and so on.

The Fibonacci sequence is used instead of the normal number sequence (1, 2, 3, 4, 5, 6, 7, etc.) because its numbers increase relatively, and that makes for easier estimation. The nonlinear increase makes it easier to make a distinction between two estimates. Consider this—on a scale of 1 to 20, telling the difference between a 12 and a 13 might be hard, but since Fibonacci numbers increase proportionally in the sequence, it’s easier to tell the difference between a 13 and a 21.

The image below of the Fibonacci spiral demonstrates this concept. The squares representing the Fibonacci series increase more and more, and their differences become more apparent, making estimation easier.

Other estimation techniques such as T-shirt sizes and the bucket system also use this relative differences in size for more accurate engineering estimates.

Establishing a Baseline

The key to implementing story points is to establish a point baseline. This means having sample tasks that correspond to each point according to our Fibonacci sequence:

1 point: A copy change
2 points: Adding on-page analytics
3 points: Adding a new entity with CRUD functionality
5 points: Implementing a feedback form
8 points: Implementing a live-chat feature

Having a baseline makes it easier for the team to compare work items and assign them points. As you can see, an increase in points also means an increase in the complexity and effort required for the corresponding item. This baseline will guide us when assigning new work items a story point. The use of Fibonacci numbers on the story points makes it easier to differentiate the effort required—for instance, an 8 story point item vs. a 13 story point item.

Do not worry, however, about making this baseline perfect. It can always be reviewed and altered as the team gets more comfortable with estimating tasks using story points.

Planning Poker

Planning poker is an agile activity usually held during a refinement or sprint-planning meeting. During this activity, the team reaches a consensus on story point estimates for tasks in their sprint backlog.

A backlog item is presented, and the team is free to ask clarifying questions to understand the scope of the task. Team members are then handed cards depicting the Fibonacci sequence and asked to assign story points to the backlog item. If the cards show the same points, that point is assigned to the item, and the next backlog item is discussed. If not, team members discuss their different views until a consensus is reached.

Sharing different points of view helps identify any assumptions or areas that require further clarification. During this process, the team should be on the lookout for huge differences in story point estimates, as this might mean a backlog item is not well understood or has too many unknowns.

Setting a maximum threshold is another good practice here: this is the maximum number of points a task may have. If you set your threshold to 21, it means no tasks should be assigned more than 21 points. If a task goes above that threshold, it means you need to break it down further into smaller tasks. This helps identify huge workloads that might potentially cause bottlenecks or be stuck in WIP for the whole sprint.

Review and Adapt

As with any activities in agile, the story point estimation requires constant review and adjustments. This is ideally done during the sprint retrospective. Using story point estimation, you can easily identify the team’s sprint velocity, which is the number of points a team can complete during a sprint. This number varies per team depending on skill sets, the number of resources, and how well the team works together. While it’s always ideal to try and improve this number and thus productivity, the ideal velocity is one in which the team can complete required work items without incurring burnout, feeling overworked, or pressed for time.

The sprint retrospective, a review meeting held after every sprint, is also an ideal time to review your story point baseline. After your first sprint or two, the engineering team will have a clearer idea of how much effort and work each task requires.

Conclusion

Estimating engineering work is a complex but crucial part of ensuring your project’s success. Story point estimation provides improved estimation by looking at the effort required to complete a particular work item rather than using the traditional approach of estimating work based on time, which can be unreliable.

It considers the complexity of the task, as well as any unclear requirements. Using this method, the team must establish a consensus to assign points to a particular task based on the Fibonacci sequence, which measures the complexity of tasks relative to each other. It also makes for faster and easier estimates and over time helps you determine your sprint velocity. This will eventually lead to more accurate estimates tailored to your team and their productivity.

Agile tools like Status Hero can help you implement story points within your team and provide more accurate estimates. Status Hero is a work communication tool that simplifies your project management by removing time-consuming status-update meetings and other interruptions from your workflow, replacing them with real-time reports. Status Hero also integrates into all your favorite tools like Jira, Slack, Github, Asana and more, collecting data and gathering unique insights into the team’s productivity, accomplishments, blockers, and mood. This data can be very useful in sprint retrospectives and planning poker events, which are core to producing solid agile estimates.

By Michael Nyamande. A Digital Product Manager by day, Michael is a tech enthusiast who is always tinkering with different technologies. From web and mobile frameworks to NoCode development, and recently blockchain development, he believes in the problem-solving power of technology.

One-on-One Meeting Template

Status Hero Editorial Staff — Wed, 25 May 2022 16:09:19 +0000

1:1s are one of the most important tools you have as a manager. Use this template to create a shared agenda with your team member or manager to easily track decisions, topics, actions.

Overview

One-on-one meetings continue to be the single best tool for a manager to build rapport, ensure alignment, and keep team members active and engaged in their work. They're also one of our favorite topics.

Throughout my years as a manager, I took various approaches to one-on-ones.

I tried keeping them very informal, but that caused us to miss important topics from time to time.

I tried adding more structure, but then one-on-ones became more like status meetings. 😱

What I've found to have the best balance is surprisingly simple. Use a shared document (like a Google doc) that you and your team member both have edit access to. Each of you should add discussion items throughout the week in advance of the meeting. Use a basic structure to make sure important topics are discussed, including priorities and blockers and also career and personal discussions.

When you meet, have the document open and use it to guide the discussion as well as record notes, decisions, and action items. This way you can easily refer back to the document if you need to refresh your memory and nothing gets lost.

Each time you meet, use a new entry in the document to keep a chronological record of conversations.

If you want to try this with your team, we have a simple template that can be used to help you get started. There are actually two versions available of this template. One that is the blank template, and one that has example content filled out to help you see how the template should be used.

Give it a try and don't be scared to tweak the format to whatever works best for you and your team!

Template Downloads

Team Handbook Template

Status Hero Editorial Staff — Wed, 18 May 2022 13:58:40 +0000

Team handbooks make it easy for everyone to know how your team works. Use this template to create one for your team.

When you're new to a team, it can take weeks (or months) to get fully up-to-speed on the tools, processes, and workflow. This can be even harder on a remote team because people may be hesitant to ask questions in public channels or bother team members with DMs, fearing they'll be perceived poorly.

What is a team handbook and why should my team have one?

Quickly onboarding new team members is critical for their (and your) success. A handbook is an easy way to make a portion of that process self-serve. You can capture important information like team rituals, roadmaps, common resources, and a glossary of terms. Having foundational information easily accessible and organized makes it a lot easier for new team members to get on the same page as the rest of the team.

At Status Hero, we created a handbook just for that reason - to make it easy for new team members to get up-to-speed quickly.

We thought that other companies and teams may find this format useful too, so we decided to make it available for everyone to utilize.

Here it is.

Team Rituals

This section should include an overview of your team’s rituals. Each ritual should include a brief description of its purpose, cadence, and length.

Typical examples of rituals

Daily standup
Weekly refinement and planning
Bi-weekly/monthly company meeting
Sprint Demos
Sprint Retros
Quarterly outings
Meeting free days

At Status Hero, we keep it lightweight.

Daily check-ins - using the Status Hero app and performed at 9 AM (local to each team member’s time zone)
Weekly coordination - Wednesday afternoons for an hour

How We Work

Explain the lifecycle of how your team works. Related to rituals, this section will include how you do planning, execution, and shipping of features. Things to consider including:

How roadmaps are created and updated
How work is broken down
How releases are shipped to customers
How testing is performed
How new products are exposed to users (ex: all at once, rolled out, a/b tested)
How release communications are sent to users

Tools and Environments

Outline the various tools and different environments that your team uses so new members can quickly understand what tools are available and where to develop, test, and deploy. Provide direct links to the tools when possible.

Example tools

Project management software like JIRA or Trello
Communication tools like Slack and email
Wikis or other documentation
Log or monitoring tools
Analytics tools

Example environments

Development
Staging
Production

Communications

In order to avoid communication debt, make it clear for your team what you expect in terms of response time and how and when to use certain communication channels.

Asynchronous vs. synchronous communication
Communications that need to be read (ex:team announcements, HR notices, production issues)
What should be communicated in chat vs. email
Policies for monitoring certain channels, like a Production Issues channel
No communication time blocks (like “no meeting” days but instead are blocks of time where communications are on hold)
What can be ignored

Meetings

Similar to communications, make it clear what you expect for your team in terms of meetings. Include information that helps your team manage their time and feel empowered to avoid meetings without a purpose.

Required meetings
When you can ignore a meeting
- No agenda
- Not critical
- Redundant
- Manager can go instead
What warrants a meeting (and what doesn’t)
Meeting etiquette
Shared calendars

Where We Work

Include policies for working from the office, working from home, and working remotely outside of the home (Ex: coffee shops, co-working spaces). Does your team have a work from home day (or a work at the office day)? Detail that info here.

Analytics & KPIs

Data is critical to understanding a product and its users. Make it easy to access and analyze the data for your team. Use this section to share KPIs, performance, and trends. The KPIs you choose to include here will depend on what’s important to your team. Consider metrics like visitor:trial conversion, trial:pay conversion, retention, CAC, MRR, and ARPU. Depending on your team, you may have other unique metrics that you choose to track like engagement with individual features. For Status Hero, some of our unique KPIs include the number of team members and their checkin rate.

Our Users

This section should include information about your users and target customers. If you use personas, link to them here. If not, list out the typical users and what they care about. Do you serve a specific industry? Or a specific type of user like software developers or data analysts?

Other things to consider include testimonials, quotes, demographic data, or links to research videos. The goal is to make it easy for someone to visualize and understand who they are building products for. Empathy is key.

Roadmaps

If you have a roadmap document, link to it here. That way new team members or anyone that is curious can see what your team is focused on.

Glossary

Here’s where you can document all of the TLAs and other unique vernacular at your company so people can understand discussions in meetings and documentation. Include things like project code names, acronyms, or other labels that an outsider wouldn’t understand.

Team Specific Sections/Info

Beyond the areas outlined above, feel free to add more sections as needed. The main goal is to make it easy for new (and existing) team members to find and self-serve all of the information that they may need to reference or use regularly.

Conclusion

And there you have it. Create and share your team handbook with folks from your team and ask them to contribute to it. The creation and upkeep of the handbook should be a collaborative and team-wide effort. That way, people will be more committed to following it too!