How We Work
We do Agile
We build software. The way we see it is a collaboration between multiple people in the team with sufficient knowledge on the domain and clearly understand the project vision that they can quickly adapt to the changes in the market. We adopt the Agile philosophy at this level.
Also, based on that philosophy, we apply the Scrum framework, which we find out a good fit for us. There are no specific roles in the team at the beginning. There is only the team member who has autonomy and responsibility to meet the goals of the sprint. And there is the Scrum master who is the team member turning into a coach. He works to remove any impediments that are obstructing the team from achieving its sprint goals. The role was supposed to be temporary. A mature team doesn’t need a permanent coach.
Cycles
We work in an 8-week cycle at Dwarves Foundation. There are typically six cycles to a year. This fixed cadence serves to give us an internal sense of urgency, work as a scope hammer to keep projects from ballooning and provide a regular interval to decide what we’re working on.
The idea is not that everything we ever decide to work on has to take eight weeks or can be completed in that time. However, rather that we think about how we can break big projects into smaller ones that can be done in that amount of time, and that we bundle smaller things into a presentable scope of work that can be discussed.
A budget thus limits work, and the budget focuses our discussion about what’s reasonable and what’s not. When a project starts slipping on its budget, the first approach should be to scope hammer the domain – and certainly not make it up by working more hours! Most things we work on can fit within eight weeks.
Cooldown
In between each cycle, we spend a week cooling down. That’s the time to deal with various backlogs or bug smashes, writing up what we worked on, and figuring out what we should tackle next. It’s some times tempting to add cooldown onto the end of the cycles, as a way to fit in more work. However, the goal is to resist this temptation. Yes, sometimes a little spill-over will happen, but it’s helpful to think about the end of the normal cycle as “pencils down.” That means that by week 4 of a normal cycle, we should be winding down, getting ready to launch, make sure QA is lined up, and all the other work that happens during and after the launch of new projects.
Meeting
All the meetings could be found on Basecamp Schedule.
All-hands meeting
The all-hands meeting happens at the end of every cycle. The Dwarves look back and decide what to do next.
Team meeting
At the same time, you are a member of either Programmer, Designer, Operation or Business team. We have a team meeting on the last Friday of the month to sit down together. This is the guideline so if in any particular circumstances the team lead can require to adjust the number of meetings.
Project meeting
Every project has its meeting schedule. It should follow the company Cycles and Scrum guideline with at least Sprint Planning Meeting and Sprint Retrospective Meeting.
Communication
It’s hard to keep up on what everyone is doing and what it means if you just watch the stream of latest activity scrolling along in Basecamp. (It’s also a waste of time and source of stress to even try.) Instead, we have four chief mechanisms for keeping everyone in the loop about the work that’s going on.
First, there’s the daily question of What did you work on today?, which supplies the nitty gritty details, but as a personal narrative. They’re a great conversation starter if you see someone working on something you either care about or want to learn more about. Please do use them as such! You’re obliged to answer this question at least twice a week when you’re not out.
Second, there’s the weekly question of What will you be working on this week?, which details your intentions for the coming week. Everyone is obliged to answer this question when they’re not out.
Third, there are heartbeats. These are the team versions of What did you work on this cycle? This is where we summarize and celebrate the work that’s been done. Every team lead is obliged to write or designate someone on the team to write, this account one week after a cycle has ended.
Fourth, and finally, there are the kickoffs. These are the team version of What are you going to work on the next cycle? This is where the plan for the coming eight weeks is presented. Every team lead is obliged to write or designate someone on the team to write, this account before the start of the new cycle.
These mechanisms work together to free individuals and teams to run their days and cycles with confidence and independence. We have six opportunities per year to make big decisions about what to work on, and the rest of the time should chiefly be spent carrying out those short-term plans. By having clear expectations for communication, it’s easier for everyone to build trust in where we’re going and why.
Pitches
Whether you work on product development or not, your voice and observations can help determine what we should be working on. The way to exert this influence is through pitches.
Write-up your idea of a new thing, an issue in daily work, a change to a feature, or any other product development you think we should be considered as a fully considered post (the more specific, the better). This gives the whole company a chance to consider and respond to the idea, and then we’ll have the idea encapsulated in a post, available for reference at any time.
There’ll always be more pitches than we have time to field, though. So it’s important to have realistic expectations about what will happen after you posted your pitch. The default is simply that everyone involved with product development (and probably most everyone else in the company) will read and consider your pitch. That’s a win right there. Even if the full pitch doesn’t make it in, it can impact other product decisions by shining light on a weak point.
Han and An is the team evaluating pitches for inclusion in the next cycle. Before the start of every cycle.
Raising an Issue
From time to time people may have problems or concerns about their colleagues, customers, company leadership, work environment and so forth. We want everyone in the team to be empowered to raise an issue and have it dealt with swiftly and fairly.
Have a conversation with the person involved: The first thing you can do, if you feel comfortable and able, raises the issue directly with the person concerned. This direct and informal approach is encouraged, and we expect your colleagues who are approached responsibly to respond similarly. This approach may be particularly appropriate in dealing with matters of speech and expression, where individuals may not be aware that their behavior is causing distress.
Ask a colleague to intervene on your behalf: You may ask a colleague or leader to intervene informally on your behalf. In some situations, you may not feel able to approach the person or people involved directly and so going via a third party to raise your concern for you informally is another option available to you. In particular, if you have a grievance with a leader and feel unable to raise it directly, you should raise this issue either with another leader or with a colleague who can raise it with a leader for you.
If they can’t help to resolve, you can talk to Han.
With managers of one
Managing at Dwarves Foundation is a part-time occupation, next to being involved with doing the work itself. This means we rely on everyone at Dwarves Foundation to do a lot of self-management. People who do this well qualify as managers of one, and we strive for every one senior or above to embody this principle fully.
That means setting your direction when one isn’t given. Determining what needs to be done, and doing it, without waiting for someone to tell you to. A manager of one will spend their time well when left to their own devices. There’s always more work to be done, always more initiatives to kick off, always more improvement to be had.
A typical working day
9 am Monday, there is an Operation meeting between the head of all the team. They check up the status and list out what they need to do this week. Basecamp sends out the Digest email about recent activities. Basecamp start questioning “What will you be working on this week?”
10 am Monday, there are several Sprint Planning meetings to get people on the ground if it is the first Monday of the sprint. People start working.
12 pm, lunchtime and take a short break to 1 pm.
3 pm Friday, the team close the sprint to do Retrospective meeting if it’s the last Friday of the sprint.
4 pm Friday, there are several team meetings of Engineer and Design team if it’s the last Friday of the month.
5 pm, Basecamp start questioning “What did you work on today?”
6 pm, the Dwarves leave the office.
Remote
With the deep understanding that Work-Life balance is the real deal. We decided to pick this style of remote working as a primary way to work for the whole company. And everyone can choose to follow it or not. It’s optional but highly recommended.
We believe that a happy person can deliver 10x quality output compared to others. You cannot stay in the room all the time and can be creative at the same time. People should have the right to use the time of their own and to work anywhere as long as it does not violate the company values.
We don’t want to manage your chairs.
We encourage the team to work remotely. We want our Dwarves to wake up at 7 am on the beach, grab a coffee and start doing the job that they love. Or spending the day in a coffee shop downtown to be more socialized. Or take their time to breathe the fresh air in Da Lat or Chiang Mai. Or the Dwarves can choose to stay at home with their kids at the cozy working corner to enjoy the alone-zone, best zone to focus and get things done.
It’s also important to note this privilege is on a case-by-case basis and you need the approval from the lead.
We head toward craftsmanship
Software Craftsmanship is all about putting responsibility, professionalism, pragmatism and pride back into software development.
Craftsmanship is not enough to guarantee the success of a project but the lack of it can be the main cause of its failure.