The 4 Day Week problem we’re solving with NASA – Not Another Standup App

As you probably know if you’ve ever been to our blog before, In December 2022 resolution kicked off a trial of the 4-day week. It hasn’t been easy: adapting to working 8 hours less per week without losing productivity is a heroic challenge we have gladly accepted.

In this article, I’m going to give some tips based in our experience that can be helpful for any company considering a similar experiment. To do that, I’ll focus on the example of how we are tackling one of the main areas for improvement: our heavy meeting culture.

But here’s a quick teaser if you want to jump to the conclusions: we built a brand new app to run efficient daily standups based off our Jira data. We named it NASA – Not Another Standup App. And owned up to the name with this epic ad:

Tip # 1: Build Trust

The first time we ever talked about the 4 day week, we had a very open debate. We discussed whether it was something we actually wanted, why we wanted it, and how it would make a difference. Chris, our Co-CEO, even asked how we would feel if the trial were to be canceled.

I’ve already described this moment in an article about that debate:

As we insisted that we’d be fine yet sad to go back, we were silently committing to change. We’re going to try, we’re going to be the best version of ourselves, and we’re going to succeed!

In order to build trust, I think it’s key that everyone feels part of the decision. Each of us has been involved in picking up the exact model and the right processes.

Even as we monitor productivity, we never compare teams or individuals. Metrics are there to help, guide, and coach. To make progress visible. To build trust and a shared understanding of where we should go next.

This is, for example, how we used Umano to help us with accurate story point estimates. As you can see in the picture, the average time spent per issue is proportional to how many story points we estimate.

Tip # 2: Get a realistic, no bull$*!t picture of the status quo

So yes, metrics are important. They help build an assessment of how the team is collaborating, what’s pushing us back.

But to have a realistic picture of how we work, there is nothing like a good look in the mirror.

And this is what we saw: we were having way too many meetings.

Essentially, we were still working as a traditional company that sits in the same office; not like the distributed team that we have become in the last 4 years.

If we didn’t change this culture, meetings were going to squash us.

Tip # 3: Break the status quo

When you have trust and a shared vision, you can afford to break stuff. Be the bull in the china shop!

This means different actions for different companies. In our case, we had to kill Zoom addiction. We knew that we’d gnaw at our fingernails while we fought withdrawal for the first couple of weeks. But it gets better over time!

In fact, we’re just starting to see that having less and shorter meetings is possible if we cover the groundwork upfront:

• Always take meeting minutes. For group meetings, we use AI for full transcripts, post them into Confluence, and review them.
• Create action tasks in Jira. This is an integral part of our follow-up process. Every decision and action item from a meeting is transformed into a task within Jira. This keeps everything traceable and allows team members to stay on top of what they need to do next without scheduling more meetings.
• Enable asynchronous collaboration. The more we use tools like Confluence and Jira, and the less we use apps like Slack and Zoom, the easier it is for everyone on our team to know what’s going on, even despite the different work schedules. One essential piece has been a tighter integration between Jira and Slack that makes issue comments way more effective.

Tip # 4: Build a central hub

Jira is at the very core of how we collaborate: our entire toolchain works because it’s connected to Atlassian’s productivity motherboard.

Tasks, decisions, action items… they’re all in Jira, ensuring full transparency and maintaining a full record of what we’re working on at any given time.

The issue with the daily standup

In spite of all our progress, we have learned that status updates are not easy to capture in Jira. We did try using Atlas, but we’re probably too small of a company for that.

We also looked around at standup apps that we could connect to Jira, both in the Marketplace and beyond… but we couldn’t find any that was good enough for our purpose.

In the end, we decided to build our own standup app. We started using it in June, and and we have just released it to the Marketplace!

The solution to our meeting problem has become a new product: NASA – Not Another Standup App

I know that building an app to solve a problem for a 30-people company might seem like an overkill. But that’s how we built our success with SAML SSO back in 2012, so we’ve decided to stick wit it!

In this case, we believe that the app is very flexible and can be used to capture any type of scheduled feedback!

Essentially, you can benefit from the app if you’re interested in combining the following factors:

• Regular, qualitative feedback. Since every user can be invited to the work stream, the app is a great way to document open feedback fairly, without HiPPos or biases.
• A tight connection with Jira issues. The app makes it very easy to pick the Jira issues that you’re working on to comment on them.
• Highlight milestones or blockers. Flag a problem, report any issues as blockers, or simply tell everyone that you’ve finally completed a critical task that was blocking others.
• Combine async and sync comms. Since daily updates must be prepared in advance of the meeting, members who can’t attend will still be heard by the rest of the team. At the same time, meetings are way more effective since there is a lot more structure to them.

Want to see it in action? Here’s the full tutorial:

Three ways to use NASA – Not Another Standup App

We have designed the app to match different communication needs and preferences. As an illustration, I will offer three examples of how we’re using it internally right now.

Besides driving two classic agile ceremonies (daily standups and sprint retrospectives), our cloud team is also using the app to gather interest and discern whether they need to meet to discuss any topic in depth.

NASA Example #1: Daily Standup Updates

Daily standup meetings are the #1 use case, and this is arguably what any other company will start with. There’s nothing too surprising here, besides the pleasant experience of having the standup seamlessly connected to your Jira issues.

Questions

• Do you have any blockers?
• What did you do yesterday?
• What are you working on today?

These are the default questions – but you can customize to, for example, ask for pull requests, testing, or any other collaboration needs that will help the team keep in sync.

Preferred feature

• Picking issues from a shortlist

Documenting blockers and including them in our team summary has proven to be incredibly beneficial. It enables us to be more proactive in offering assistance to overcome any obstacles.

NASA Example #2: Bi-weekly retros

As a team of agile teams, we’re working more and more towards a model where sprint retros help us share work externally and generate synergies.

The standup app is essential for documenting which epics and areas of work suffered from poor planning or hit any obstacle during the sprint, and spreading that knowledge through the company

Questions

• What went well?
• What should we stop doing?
• Did we achieve the goal?

Preferred feature

• It’s really simple, but I love the visibility of comments on our different epics! Makes it very easy to have an overview of what everybody feels, and how it’s related to our ongoing work in Jira.
• Overall completion rates are very helpful to look at also once the sprint is about to finish.

NASA Example #3: Do we need to meet to discuss any cloud topics?

We have just restructured the number of recurring meetings that we do, and decided to drop a generic cloud meeting that was happening weekly.

However, our cloud Team Lead was concerned that we would stop discussing topics that affected all cloud developers. For that reason, he suggested having a stream in the app simply to gather potential topics of discussions, and then decide whether or not to run the meeting on that week.

Questions

• Do you have any topics to discuss?

Preferred feature

The Team Journal in this case is just a great way to going through all the areas where the team is reporting that they want to share knowledge, learn from others, or skill up.

Conclusion

If you ever try it yourself, you’ll agree with me: A 4-day week can be very testing for your collaboration culture. The scarcity of time creates stress on the existing processes, the cracks show – and then you know what needs to be fixed – even if you still don’t know how.

I don’t know how far we are from being entirely happy with our communication culture. Or when we’ll be able to say: each of our meetings is super productive!

But I know that we’re not sitting still. We’re making changes, we’re not compromising. And we’re even innovating and creating new products as we go.

NASA – Not Another Standup App is an audautious answer to two very different challenges. From a business perspective, resolution has embraced the strategic move towards the Atlassian cloud, and more specifically to developing apps with the Forge framework. The Standup App is our largest cloud app, and it’s built with Forge.

From a team perspective, we’re learning how to communicate asynchronously. Our standup app is essential in this collective training, as it allows us to build on top of Jira, and get better at working together.