Leadership & Organization
Effective teams are well organized teams. At Code Hangar our teams are self organized, meaning we don’t have dedicated project managers or scrum masters. Typically we have one team member who owns the project, and with the assistance of the rest of the team, makes sure that tasks are scoped properly, defined well, and that blockers to progress are identified and addressed. Since we are all actively contributing design and code, we have shaped our agile processes to allow us to spend a small portion of our time managing ourselves so that we can put the majority of our time and effort into the actual work that delivers value to founders and their customers. Every sprint cycle (see more about sprints below) we do a retro on our process, identify what's working and what's not, and adjust our process accordingly.
Slack is a messaging app built for teams. It allows your team to engage in real time communications privately with other team members or within channels created for specific purposes. The primary channels my team uses are
- #general - Where all slack members can communicate together about anything
- #staff - Where staff-only communication happens. For us this is a private channel accessible to only staff, because sometimes we invite clients into our Slack group and want to keep them out of these communications.
- #daily - This is our most important channel. It’s where we do our asynchronous Daily Standup. Every day, team members are expected to post an update which includes:
- What they completed yesterday
- What they plan to complete today
- What, if anything, is blocking them
- #integrations - This is the channel we integrate with our remote code repositories. It tells everyone on the team when code is pushed and merged, and when builds succeed or fail. It’s one of our most valuable channels.
- We have a number of other channels too like #design, #development, #fortnite... where conversations are kept to the theme of the channel name. Channels help us organize and find important conversations later.
Additionally we use Slack Reminders to schedule regular reminders to help the team remember to do certain important things. For example, we have a daily reminder to post a daily update. We have weekly reminders to review OKRs. These reminders save me, the primary team manager, a lot of time, and helps the team remember to do small but important things while they are neck deep in their project work. :)
We use Google Meet for our mandatory Weekly Team Video Call. Unless someone has a bad connection, we ask that all team members use their cameras so we can have some face time.
The call lasts 1 hour and the format is:
- Team Updates: Everyone on the call takes about 5 minutes to explain what they have been working on in the last week, what’s going well, and what they are struggling with. It’s sort of like our daily update, but instead its face to face, and covers a whole week.
- Client Project Reviews: As a team we go through all active tasks for each project so the team can get an idea of our overall progress, what has been completed, what is in progress, and what has not been started. We use this time to assign any unassigned tasks, add or modify Acceptance Criteria, and answer any questions.
- Monthly Financial Overview: The first Weekly Meeting of each month is reserved for our overall company financial report. In this report we share with the entire team how much money we earned in the previous month, how we earned it, how much we spent, what we spent it on, what our profit was, and what are financial goals are. I learned this from working at a company called Skillcrush, where the CEO would present these numbers to the team every month. I thought it was so helpful and empowering as an employee that I started doing it with my company. I find that it helps everyone understand the overall state of the company, keeps senior staff accountable, and helps junior staff feel trusted and valued. Honesty and trust go a long way in keeping a team productive.
Startup founders have reasonably big ideas about what their apps should do and it can be overwhelming for a small development team to process all of it. In reality, no team can process all of it at once. An app must be built over time, so it is important for the team to break down the overall application into smaller parts that can be completed at regular intervals as part of a Target Release Schedule or “Roadmap”.
But, it's not enough to simply break a large project into smaller parts, the parts must also be strategically prioritized. At Code Hangar our priority is rapid release of minimum viable software, so we prioritize features based on:
- Impact: Value a feature will provide to customers or the business
- Effort: A combination of time, uncertainty, and difficulty to complete a feature.
In an asynchronous effort between founders and developers, we score each feature on a scale of 1-5 for impact (by founders) and effort (by developers). The features that are high-impact-low-effort are typically done first those that are low-impact-high-effort may never get done.
Once all features are ranked and prioritized, they are placed in a Target Roadmap which always remains open to adjustment as the impact or effort score for features may change. The best software we have found for tracking a roadmap is a simple spreadsheet.
Sprints are useful for helping a team consistently deliver releasable work at regular intervals. Sprints can be any duration, a week, 2 weeks, a month, as long as each sprint is the same length. I find two week sprints to be most comfortable for my team. We sometimes use one week sprints if we are in a rush. I’ve already written a lot about how we do sprints at Code Hangar, which can be found here.
I don’t actually know what SCRUM means but it refers to moving individual tasks through a defined workflow, which at its most basic tends to include “Todo”, “Doing”, and “Done”. These workflow categories are usually organized as columns that tasks are move horizontally across. A great tool for enabling a scrum workflow is Trello, with its simple column based organization of cards.
The simple “Todo”, “Doing”, and “Done” workflow works great for non-development teams, or dev teams that are new to SCRUM. At Code Hangar we have a more sophisticated workflow for our development team which includes “Ready for Code Review” and “Ready for Testing” prior to “Done” which helps us ensure quality of work. We started out with Trello because it’s free, flexible, and easy to use. In the last year though, our projects have demanded more sophisticated organization so we migrated over to Jira. I recommend that small teams stay away from Jira as long as possible. While Jira is powerful, it is very complicated, and many companies have dedicated Jira Managers because of it. It was a pain to get Jira set up for us, but now it's pretty simple to use day-to-day.
Acceptance Criteria are the simplest way to define what “Done” looks like. The creation of Acceptance Criteria should originate from stakeholders, be presented to developers, and clarified as needed. The typical format of Acceptance Criteria describes the acceptable outcome of completed work, rather than describing what work needs to be done. Here is an example:
- Poor AC: “Build the registration page”
- Good AC: “Users can create an account with email and password”
Acceptance Criteria, when done well, can actually become the testing criteria for whoever is in charge of QA (Quality Assurance) testing. If the Acceptance Criteria is not met during testing, then the work can be rejected and returned to the developer.
Story points are used for sizing taks. Many development teams, including ours, use the Fibonacci sequence for Story Point numbers. The idea is that the larger the story is, the more uncertainty there is around it and the less accurate the estimate will be. Using the Fibonacci sequence helps teams to recognize this uncertainty, deliberately creating a lack of precision instead of wasting time trying to produce estimates that might also carry a false degree of confidence. It's much easier to say: it's more 8 than 5 than to say it's more 8 than 7.
- (.5) A near instantaneous tasks with no uncertainty
- (1) A simple task with little to no uncertainty
- Use 1 hour as a rough gauge
- (2) A simple task with little with some uncertainty and/or a reasonable amount of routine work
- Use 1-3 hours as a rough gauge
- (3) A more complex task with little with some uncertainty and/or a lot of routine work
- Use 2-5 hours as a rough gauge
- (5) A complex task with a fair amount of uncertainty and/or a lot of work, might rely on outside factors or dependencies
- Use 4-8 hours as a rough gauge
- (8) A complex task with high uncertainty and/or work load, heavily relies on outside factors or dependencies
- Use 1+ days as a rough gauge
- (13) A complex task with extreme uncertainty and/or work load, heavily relies on outside factors or dependencies
- Use 1 week as a rough gauge
Keep in mind that the time estimations are meant to serve as a rough mental guide, but your sizing estimates should be based on the level of effort, complexity, uncertainty, and difficulties in testing. To keep completion of work as predictable as possible, it is best to break down tasks such that they can all be given a size of 1.
Toggl is a tool for keeping track of time spent on various tasks and projects. We have used it at Code Hangar since the beginning because they offer a free tier, which got us by before we were making enough money. Now we have cheap paid plan that supports our larger team.
For an agile team, the purpose of time tracking should be for use in projections and estimations, not for accountability. If time tracking is used for accountability, the team either won’t use it, or they won’t use it honestly, and because accuracy is important, you’ve got to give up on time accountability. Quality of work should be the measure of success, not time spent.
At Code Hangar we don’t care how long someone works on something except that it helps us estimate how long similar tasks might take in the future.