Written by As a Scrum Master, Project Manager or any other project management role you can have, removing impediments is part of your daily routine. They come in many forms and sizes, ranging from organizational to human ones.
But there are also technical impediments, those you annoy ask your beloved developer teammates for help if you don’t usually code.
The truth is that big part of those roadblocks can be tackled with a single line of code. Yes, you can work on low hanging fruits and have a lot of fun!
Which technical impediments can you work on?
Recently I had the opportunity to code a little bit to help the team. I can suggest the following topics, where you can achieve positive outcomes with very little effort:
Outdated project readme files
It’s just text, but it’s a good opportunity to hone your GitHub and markdown skills without breaking stuff.
Besides helping a new member on his onboarding process, it will also spread the message that it’s important to keep it up to date.
Outdated Boxen manifests
Some of our folks use Boxen to set up their environments. We often forget to update the project’s manifest. One more chance to practice. Go for it, your teammates will be grateful when they perform another clean OSX install!
Front-end fixes (color, text, positioning, size, UI behavior)
They’re small, they’re easy to fix and may bore a developer to death. But to you it’s all new and rewarding. Those represent the majority of the commits I’ve done.
As you become more experienced and confident you can expand into other areas, it’s just a matter of curiosity and opportunity.
What are the benefits?
Between one commit and another I noticed some advantages. Below are some that might also work for you:
Codebase knowledge
As you perform fixes, you get in touch with different parts of the code. It will naturally increase your awareness of where things come from and where they belong. From now on when you hear about a bug you will probably track its origin with ease.
This also makes grooming sessions more productive, since you are more familiar with the effects a new feature will bring to the application, improving your negotiation superpowers.
Better communication and relationship
Good communication saves a tremendous amount of time and energy. When you deal with code, you learn the technical vocabulary. In your next conversation with the team, people won’t need to translate jargon so you can understand. The same applies in the opposite direction.
In my opinion, a manager that can code also increases the sense of fellowship, improving the overall relationship among team members.
The feeling of shipping code
My first commit made some checkboxes to be selected by default. Nothing big, I know, but when I saw the customer using it I realized that shipping code feels amazing!
This brings the sense of belonging and increases shared ownership. You should give it a try!
Working with Pull Requests
At my very first day at Plataformatec, I realized that all teams were using Pull Requests. Shortly after, I figured out why we were using this technique. But I really understood it when I first submitted one of my own. Reading code and discussions added value to me, because I could see what was going on without interrupting people. Discussions also acted as a thermometer, revealing some insights about team relationship.
Learning how to write tests
Your code will break some tests (believe me, it will). Panic? Never! Go on and learn how to write and run automated tests. It’s not that hard. Ask your friends, they will be happy to teach you.
Learning about tests will help your communication with developers and reinforce quality culture as well.
Waste reduction
Waste is a fierce enemy and every chance to beat it must be taken. Coding can give you some opportunities to do so.
Every little fix you deal with is one less interruption and context switch for a developer. Every conversation you join in a Pull Request is a shorter feedback cycle being nurtured and less time being spent in queues.
These and other factors combined can positively impact the team’s performance.
Where to start?
I recommend following these steps:
Learning git and Pull Request basics
Here in Plataformatec we use GitHub, so finding documentation about Pull Requests wasn’t difficult. If you use it as well, you can browse Github’s Help and even use our Guidelines as a reference. If you don’t, I’m sure you can find plenty of content about your version control tool with a simple Google search.
Practicing in a controlled environment
Look for a repository that you can commit without spreading panic if you mess things up. For instance, I have practiced in our Campfire bot. If you don’t find any appropriate repository, you can fork a public project on GitHub and use it as your sandbox.
In this phase my colleagues helped me a lot crafting my first Pull Request, I bet yours will do the same. Don’t be shy and ask them for help!
Looking for and working on impediments
You have just developed a new skill, now it’s time to use it! Look for things similar to those examples I suggested and invest a little time in them. A couple of fixes later you will be able to work more independently, and the results will start to come.
Is there any pitfalls in this practice?
If you do things in a careful and balanced way, they will happen just right. But there are some traps you should avoid:
Creating dependencies
Remember that you are coding to help removing obstacles. If you turn yourself into the person responsible for maintenance, you have just become a bottleneck for the system (or an irresponsible developer, as you prefer).
Forcing people to code
Despite the several advantages mentioned, not every manager likes to code. Don’t force people into doing it.
Micromanaging
Joining Pull Request discussions brings great value. Micromanaging doesn’t. Don’t even think of using Pull Request discussions as a control tool. Trust your team!
I hope this blog post can help you and your team to improve. Have you ever tried something like this? What are you thoughts about it? Share them with us in the comments below!
Hi Wesley. I agree with you that coding can put you closer to the developers, that it can make both of you speeking the same language. But, as a scrum master or agile coach, don´t you feel that when you code you are not permiting the developers to learn something about their jobs or to improve how they do their jobs?
I think that we improve the way we do our jobs when we feel some pain. Example: outdate manifests, eventually, would cause pain to developers. Devs would do some boring work updating manifests. Devs could start to think in a way to automate this part of their jobs.
Hi Rodrigo!
That’s a very good point. It can happen if the manager becomes the person responsible for unpleasant tasks related to code. As you said it can hide pain points.
A good approach is to treat coding as another tool in a manager’s toolbox. The idea is not to transform the manager into a chore guy, is to make him capable to help in a new way when is reasonable to do so.
Thanks for the feedback 🙂
The principle is sound but the two main risks I see are:
1). When you don’t code regularly the overhead of learning or relearning can be very high, and the costs of mistakes also high. I worked as a programmer years ago but truth be told I was never great at it – adequate would be a good description.
2). As a manager your main role is to ensure the team can do what it needs to do – you as manager run interference, facilitate, remove blockers, keep the external stakeholders happy and off the team’s backs etc – this is usually pretty much full time. if you get distracted into coding you risk not doing the coding well, becoming an impediment yourself and doing a less than optimal job of managing the issues that can negatively affect the team.
Years ago I wa a programmer on a project that ht some troubles and the project manager (who had started as a programmer on that system years before) got involved with coding. What he wrote worked as such, but left sub-optimal code and also obscure defects that took weeks to work through. His contribution had some value when he did it (got us over a hump)_ but left longer term issues that probably outweighed his involvement.
Not saying you should not get involved but bear in mind the potential downsides as well as the potential upsides.