Tech Talk: "The efficient DevTeam" with Hannes Gerstlbauer
Find out what's most important when managing a development team and how you can make the work more efficient.
To deliver decent software, the team needs to be organized. Every team is different and each leader will manage the team individually. From experience, you can see that some things are more important than others.
Here are a few pieces of advice I can give....
Be specific about what needs to be done
People come to work as normal. They sit down - or these days "stand" - at the computer, work off what's required. Then they go home. But if the task isn't properly formulated, things don't go so smoothly. Instead of working on a task, a lot of time is lost in finding a task in the first place. So if the goals are not clearly defined, the developers ask around - as long as the soft skills and the time availability fit.
This concretization is also an essential point in the established product or project management methods: In the waterfall model it is the structured documentation. In Scrum, it is the structured user stories.
Divide up what is divisible
Everyone likes to mark something as done. Small successes are important, it feels much better to accomplish 10 small tasks than like somehow completing maybe half of the one big task in the same amount of time.
Not only the small felt successes are important, even just in dividing the tasks additional ideas, questions, suggestions, etc. occur. The problem is more clearly defined and the work becomes more organized.
These two points are already a very good start. Although they cannot be introduced within a week, they will definitely pay off! And if you want to go even deeper....
Test what comes out of development
Small, well-defined tasks are great. That said, it's also important to test enough. Testing should be done in an environment as it is normally done by a non-developer in the application then.
In different cases, of course, different numbers of errors are found, but mostly improvements are always found. If the functionality of code is tested directly after the work is done, this has the advantage that the responsible developer still has a good grasp of the written code and does not have to learn it again slowly.
Fair, which lasts everything
Every developer should have an idea of how much his work is worth. If you start to think about the amount of time your work takes, you will quickly realize that maybe just a few lines of code can take 2, 3, 4 hours. You will realize that pull requests, new columns in a table, creating new permissions, etc. are not "duration: zero" activities.
Awareness of the duration and cost of work also lets the development team give more accurate time estimates on projects and tasks. This is not only good for business, but also positive for the team. It is quite bad for the morale in the team if a task is wrongly estimated as 1 hour and then actually takes 6 hours.
Estimating time correctly is high school, but you can go further...
Traceability
Bug fixes. It is also important to see how much is spent on the one hand for the initial functionality, and how much on the other hand for the bugfixes.
Something like this is often provided by tools like Jira, Azure DevOps and the like. Not just approximate estimates, concrete numbers. Who? When? How long? Such numbers are important, you should be able to present them accurately to the team, often people misestimate how long things take afterwards.
"In this sprint we used 40 hours with bug fixes from the previous release.
"No way, we've already fixed a few bugs, but far from 40 hours!"
"Here's the proof."
Proposals
The team works, everyone knows exactly what needs to be done, everyone can roughly estimate the respective workload. Runs! Now you are on a level where the team can improve itself.
The Sprint Retrospective, common in Scrum, is the appropriate approach here. There should be a common place where suggestions for improvement can be made. Emails with a specific subject, a channel on Slack, etc. All suggestions should be collected and discussed together in a meeting.
The team is concerned about improvement, knows what to do and how to do it. Now what?
Processes
The more such suggestions accumulate in Scrum Retro, the more the things to consider pile up.
It is often the case that individual suggestions for improvement are discussed dutifully in the team, but then it becomes difficult in the implementation. Someone does not agree with a method, someone forgets something that was agreed upon, or unintentionally does not adhere to certain procedures. All this can happen, but if there are no big cuts in performance, you shouldn't spend too much time discussing the black sheep in the meetings. If something doesn't work the first time, never mind, just try it again.
If necessary, this can also be used to formulate clear procedures that the team should try to follow.
What's next? Try not to get bored
The developers are happy with the work they have done. Everyone knows what to do and how to do it. At this point, the team should be running pretty well. Now, experiment!
Now it's time to try something new, don't get bored. Try a new technology or a new work scheme. If pair programming isn't done on the team, try it out. If you work together all the time, try working alone. Try something new.
