2016 has passed, and people had different opinion on it. The internet seemed to think that 2016 is a complete disaster, though. Political turmoils, wars, death of famous figures, and our personal miseries propagated through social medias and memes. This meme depicts the thought pretty well:

I got my share of miseries for 2016, but the old hymn reminded me to count my blessings. I realised that through the whole year, I learned important lessons from my workplace.  One of the most valuable lesson I had was more chances to lead iOS team in projects.

Moving from a single contributor to a team leader wasn’t easy. I need to deliver stories while facilitate my teammates to deliver theirs. Along with other leadership principles that commonly known, I found out that these practices helped me on leading my team, which were establish shared grounds, foster ownership, and schedule technical retrospectives.

Establish shared grounds

Have you ever found a codebase that has different writing style on every file? Or worse, on every line? Something like this:

If you’ve been writing code for a while, you’ll know that this practice is bad. Inconsistent writing style allows us to miss details when reading the code. This make bug-fixing become harder. Even worse, it could cause a bug when somebody adding another code on the top of it. Personally, this kind of code grinds my gears, because I prefer writing and reading clean code.

I’m not making things up, since I have found such code on client’s handed over projects (sigh). The number of inconsistencies usually rises along with the project’s age. You might have found some in forms of snake_cases in a CamelCase-based language, or mixed architectural patterns between MVC, MVVM, or VIPER… or Massive View Controllers for iOS projects 😔. Along the way, I realized that none of these projects has standards set for them.

In my humble opinion, every new project should have a standard set before the development. If you’re using Git as your source control, you could put the list of standards in a README.md file. Git-based hosting sites (e.g. GitHub, BitBucket) normally show the README content on the project’s home page, allowing visitors (and new contributors) to read the standards before jumping to the code. Here’s a list of standards that I have set in projects I have led:

• Architectural pattern. Should we use MVC, MVVM, or VIPER? If there’s a modification to the pattern, kindly specify it in the README file. For example, our iOS team usually uses MVVM along with Krzysztof Zablocki’s FlowControllers.
• Project structure. How should we structure the folders? Which folder should we choose to store a certain type of class? Our iOS team usually laid out the folders based on business domain first, then type as subdomain (e.g. Views, ViewControllers).
• Style guide. Referring to the sample code above, each person has different coding style. If not specified, a project could end up with inconsistent writing style or wasted time on useless debates. I recommend every project to have a writing style guide to keep consistency and increase readability for maintainers. If you’re using Swift, you could use GitHub’s Swift style guide. Ray Wenderlich’s style guide is a good choice, too.
• Contributing guide. What’s the branching strategy for this project? How should contributors add new features or bug fixes to the codebase? If any, how much code coverage should be achieved? Who should review each pull requests?
• Dependency manager.  What are the preferred dependency manager to use for the project? How to install the dependencies? What are the rules when someone want to add a new one?

This practice seems pedantic and unnecessary, but it has helped our team to onboard new contributors with minimum supervision. It also helped us to have a “single source of truth”, which frequently referenced when we’re reminding each other. I have found that every minute shed in making this standard has paid off multiple times.

Foster ownership

Each project in Ice House normally have a two week sprint, each started with a sprint planning or story carding phase. Our team normally plans what stories that will be delivered in the sprint and recheck the assigned points for each story. To prevent the sprint from having too many stories, we ensure the total weight of stories is based on our team’s composition. For example,  with ~20 points per person, we set ~60 points for a three-person team.

In the past, I always saw practices where every story already have assignee before the planning phase ended. When I led the iOS team, I let several stories left unassigned instead. I let my teammates choose the stories that they’re interested to work on, and request their commitment to deliver those stories on the first week. The total story point weight for each person should be around the number of working days in the week times number of points worth a single day work. For example, if  a single day work is 3 story points, every team member should have around 15 story points in a normal work week.

As the sprint goes, I review my team’s progress on the start of each day, usually noting their daily standup updates and the scrum task board (we’re using JIRA) right after it. I rarely come to their desk and ask their progress, since it could disrupt their concentration. It also helped me to concentrate on delivering my own stories, too. Still, we allow others to reach us for help when needed, e.g. discuss over a bug, or review a pull request. 😉

On the start of the second week, we huddle up and share our progress on each stories. On this step, each of us choose the remaining unassigned stories to work on. Should someone has their hands full with previous week’s stories, others will help covering him/her by taking more unassigned stories. This helped us balancing our commitment while ensuring every stories in the sprint delivered well. Hey, delivering a sprint well is a win, and winning is addictive! 😉

This practice helped foster each teammates’ ownership to the project, since everyone chooses the stories they want to work on. Updates are checked regularly while keeping minimal distraction, allowing each team member to focus on delivering the stories. Plus, knowing that we delivered every stories in the sprint is satisfying! 😁

The only downside of this practice is letting your teammate to choose their stories first. Should there be a complicated feature set or stories that left by others, it’s the team lead’s job to take it. 😅 It’s always the leader’s responsibility to set a good example and lift the most weight, no?

Schedule technical retrospectives

Retrospective meeting is a crucial practice in Agile development, since it allows us to collect every lesson learned on each sprint. This practice allows us to identify practices that worked well for us, so we could do more of it in the future. It also helps us point out problems in our team and plan actions to handle them. I took this practice into my own team, with one topic in mind: how do we do in technical terms?

Technical retrospectives allows my team to discuss about (technical) issues that left unanswered because our fast-paced iterations, such as:

• Remaining TODOs. Solving a technical debt made by one person is easier when done together. 😉
• Style inconsistencies. Our style guide might not cover all cases for writing code, thus there’s always room for discussions. There was a case where the whole team used different verbs for similar methods, which were get, retrieve, and request. We decided to use “get” as the main verb for those methods.
• Possible refactors. It is common to have changes in the code as the project goes, and normally there are some refactoring that could be done, e.g. data / domain modeling.

We also took the technical retrospective as a chance to raise questions, share our learned lessons, and share ideas to make our codebase better. Through this action, we maintain our codebase’s health, increase our knowledge, and create list of low hanging-fruits that can be done during our code freeze period.

There’s one thing that should be noted for this practice – we need to ensure that the retrospective tackles ideas and problems, not the teammates. There’s a good chance that somebody made a mistake and that problem was brought into the retrospective. During the discussion, make sure that the whole team focus on bringing solution to the problem instead of bashing the person.

Since the retrospective also allows us to bring new ideas, we might need to remind that rejection of an idea is not rejection of the person who proposed it. This is not an easy pill to swallow, though. There was a time where I proposed an idea and my whole team disagrees. It’s not a pleasant moment, but later on I realized the flaw on it. One of the perks for having an awesome team to rely on, folks! 😉

What do you think about these practices? Have you done something similar? Do you have other practices that might be useful for leading an agile team? I’d love to hear your opinion! 😁

P. S. : Kudos to everyone who worked with me on 2016 – engineers, quality assurances,  project managers, designers, and business analysts! You guys rock! 🍻

P. P. S. : Dear future self, kindly add another blog post to validate these practices after you finished Steve McConnell’s Code Complete, ‘kay?