Commit #7: Useful practices for leading an Agile team

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:

func aSampleFunction() {
let something = Something()
if something.isFree {
print("hey this is free!")
} else { print("and this is not") }
if (something.isStrange) print("this is strange")
else { print("who am I to decide") }
if something.isBroken
{
print("we need to fix this")
}
else
{
print("this is good as new!")
}
print("these brackets made me crazy!")
}

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.

Continue reading “Commit #7: Useful practices for leading an Agile team”