Turn the devils in the details into your minions

Learn to restrain the devils in the details and clear your path toward productivity and shared understanding

Amir Yousefi

Follow

Apr 17, 2020 · 6 min read

No one like a software development team knows that the devils are in the details. But it is not enough. they also need to learn to restrain those devils. And if you could tame your devils, you may create minions out of those devils. So they could work for you, instead of harming you.

Minding the details is an important skill for every team. As a lead developer for years, I always struggled to mind these details. Also, recently I wrote documentation about our development process for my team so the whole team and new members can follow. To create a clear development process, I realized we need to pay attention to four parts of our development life cycle. These are major parts of any software development process that can make trouble for any team. If you have strategies and an action plan in your team for these steps, you can make sure that your development team will work in sync and will be more productive.

1. Details in defining tasks

Only a task with a description of what should be done will get done properly. If you are familiar with the Scrum method, you already know that having a clear definition of done is necessary.

To create a clear definition of done, you need to add enough details to the task.

Mostly, We add these details to our tasks:

• Task description
• Assignee
• Due date
• Planned hour
• Priority

How to sort our tasks

Next, you need to sort your tasks. There are many ways to sort the development team task. A classic and simple way is to sort all tasks in these three columns: Todo, Doing, Done. But to work as a team you may need to add some other columns as well.

We sort all of our tasks in these six columns:

1. Draft
2. To do
3. Doing
4. Today
5. Review
6. Done

Draft and Todo

First is the draft column, we put all tasks in this column, wether it has details or not. All of the features, even everything we wish to do will go here. Later we discuss each task’s importance and values. Second is the todo column, where we put only tasks that the team agreed to do. In this step, we may break tasks into smaller tasks. Also if the team can add any other details to the task they do.

After this step, the assignee of the task will add any additional details to the task. We agreed that only the task assignee can decide if the task details are enough to be able to get it done. If the assignee requires any additional details, she/he could get help from other team members as well.

Doing and Today

The assignee can put a task in the doing column when he gets the details she/he needs. Also, if your development team works in sprints, which I highly recommend, the team can put all their sprint tasks in the doing column.

The last step of doing a task is the today column. The today column is a subset of doing column. Usually, I recommend my team members to put the tasks that they want to do tomorrow in their today column. So at the beginning of the day, they already know what they need to do today. It may result in more concentration of the team. After all, we always encouraged to write our tasks down for each day the night before. Also, the whole team could see each other today’s plan and have a shared understanding of the process. Also, this could work as part of your daily stand-up.

Review and Done

After a task is done, the task assignee put it on the review column. One of the development team members can review the task. If everything is ok the task will go to the done column. Also, as a scrum team, you can review all the sprints tasks in the sprint review.

2. Development team daily stand-ups

I found daily stand-ups as a great tool to keep the team in sync. Although Scrum didn’t talk about what should be shared in a daily stand-up you can talk about these three main questions:

• What did you do yesterday?
• What will you do today?
• Is there any obstacle in your way?

It can keep them on the same page. Also, it helps the team to increase transparency and self-organize. Note that daily stand-ups are by the developers, for developers. So share whatever that works for you. I encourage my team to give a short description of their technical approach if they want. Therefore, team members can help to build a better way of doing each day’s tasks. These discussions help the rest of the team to build a shared understanding.

Another benefit of sharing daily tasks is that it keeps you organized. Telling the development team about your today’s plan keep you concentrated. This way you will be conscious about what you will do in your day. I see many developers that lost their concentration during the day. Going to the autopilot mode will result in less productivity. Speaking about your plan loudly will keep you organized and responsible for your time.

As a remote team, you may use video meeting tools. Also, you may keep your daily meetings based on text-based messages. For instance, We created a Discord channel for our stand-ups.

3. Commits and pull requests

The major product of a development team is source code. If you didn’t manage it well, the whole process of your software development could go wrong. Not only we use source code as our development team’s efforts result, but also we can use it as a way to help the team get organized and develop a shared understanding.

We as developers are so lucky to have tools like git. So let’s use it properly. If you are pushing directly to the master branch, you need to reconsider your development process. But it is not all of the matter.

We create a branch for each task. Our branches are sorted in one of these types:

• feature
• enhance
• cleanup
• refactor
• fix
• hotfix

Branch names and description

Also, the development team follows a naming convention for branches.

[branch-description]-TYPE#TaskID

branch-description: a short description of what this branch do
type is one of the above types
task id is the id of the task in our project management system

As a developer, you already know the importance of proper commit messages. Pull request descriptions are also important. As they are a way to communicate with your team, Telling them what is changed.

We mostly put a description of the changes the branch will make. Also, we mention other team members that may need to notice changes. In addition, a webhook sends all pull requests to a Discord channel so the whole development team noticed about changes.

Certainly, a well-structured git-flow helps your development team to keep concentrated and wise. Most importantly, the whole team can have a shared understanding of the source code following pull requests and branches.

4. Documentation and reporting

Without good documentation, you are not done. There are two types of documentation. First is the technical documentation. And next is your development process documentation. Although many development teams take technical documentation very seriously, it is also important to document your team process.

The technical documentation includes:

• Source code comments
• Major functionality
• Dependencies

In addition, following a test-driven development(TDD) method, all test cases you produced are a big part of the technical documentation.

In order to document your development process, you can create a shared document for your sprint retrospective results. It will help your development team to build a better development process by eliminating problems and obstacles. Also, your team can create a handbook to explain all steps of your development process. Therefore, all current and new members of the development team have a clear view of the process.

Also, our development team members report their daily works. We call it timesheets. It includes a short description of what they do and how many hours they spent. This helps us to plan future tasks with knowledge of the time they need. Besides, keeping track of the daily works helps to have a record of any obstacle or time-wasters.