On software engineering management
There is are lots of approaches to managing software engineers. I want to dispense my view.
Do you see the above meeting room are empty? Why? Because the software engineering team is building a product!
You don’t need to manage engineers. Let them build things!
- Build and refine the backlog together.
- Make the priorities clear.
- Define scope and help estimate
- Define together and understand the definition of done
- Help teams self-organize.
- Make them accountable and reflecting.
Scrum Framework tries to address a lot of this, so I will reuse common concepts from it in this document.
Build the backlog
The backlog is the most crucial thing your team has. It should contain all the tasks the team needs to do to build the product. If you are using Scrum, it is a good idea to separate Product backlog (features and stories to be implemented) and Sprint Backlog (development tasks to be done) but keep them linked.
One of the ways to do it is using Epic task type for Product backlog and regular tasks Sprint Backlog.
Refine the backlog
Both product backlog and sprint backlog should be frequently visited to refine and add detail to the tasks. Both the product owner and engineering team should participate in this because they both contribute their experience and feedback to understand the scope of the task.
Make the priorities clear
Keep the most important tasks in the backlog at the top. But make no mistake, if you would like it to be done, it should contain enough detail to make it actionable.
Add enough detail to the most important tasks
For example, “Create a registration and login page flows” seems simple and easy to do, right? But, depending on the product, a lot of things can be done differently. Here are example questions the team might ask:
- Should we create a social login?
- Do we need to verify the e-mail?
- What kind of fields should the registration form contain?
- What are the required fields?
- If we have a phone number field, do we need to verify it?
- Should we add SPAM protection?
Depending on the answers, the same product feature can take 2x or 3x time to deliver.
Scope and estimation
It is sometimes desirable to understand how much time it will take to implement a product feature from the Product backlog. There are two options:
- Best guess from previous experience
- Estimate from Sprint Backlog
Best guess from previous experience
If you and a team have experience implementing similar tasks before, you can together try to estimate the new tasks based on this experience. But remember, it will be rough, and it will be rough.
Ask every team member and ask why
It is important if everybody on the team shares their opinion and explains why they think it will take this time.
Estimate from Sprint Backlog
The best way to estimate is to refine product features in enough detail so it will be a list of actionable, independent development tasks on Sprint Backlog. This way it is easy to give an estimation for every task, and the product feature delivery schedule will be easy to understand.
Define together and understand the definition of done
You need to have a coherent view on that team means the task is done? Is it developed? Is it locally tested? Is it delivered to the testing environment? Is it live in production?
Often, the product owner view and development team view are different. It is vital to synchronize views and make a definition of done (DoD) a clear guide on how the team approaches to refining the backlog and defining Sprint backlog tasks.
It is common to revisit and change the definition of done as the product progresses.
When you start building a product, there is no live version. So DoD does not contain the “Deploy to production item”. Once you launch the product, you need to decide who owns the “Deploy to production” item in your company? Which team? In which team’s DoD it should be listed?
Help teams self-organize
Help does not mean steering the team. Discuss and explain why the priorities and delivery are essential. Help the team understand scrum practices. Establish and maintain the cadence of short daily meetings, sprint reviews, and retrospective sessions.
Understand comfortable for the team communication overhead!
Not every team would like to be interrupted every 5 minutes. In fact, I have never seen a team which likes it! Understand how the team would like to be consulted with, every day? Every week? Morning? Evening? It is good to communicate this across the company so people will respect the development sprint and focus of other people.
Make them accountable and reflecting
Communicate success to the team. Show how the features they implement are used and liked by users.
Retrospective sessions are one of the most important events your team can have
Use retrospective sessions to improve how the team works in a constructive way. Always develop an action plan after retrospective and discuss how it was executed on the next retrospective session.
