Scrum team. I was familiar with the Agile principles and practices
before joining the team, but doing Scrum hands on has been an eye
opener. Having said that, rarely a day has passed that I have not
experienced the impostor syndrome. I started imagining crazy scenarios
which would always end in someone saying “What? You don’t know what Y
means? Who hired this guy?”. All my hopes were hanging onto the “new
guy” card – but then that has its shelf-life.
After talking to some great Scrum coaches, Scrum masters and
experienced programmers, I have collected some tips that can be
applied to reduce the self-loathing when you are the new guy in a
Individuals and Interactions
What is at the end of a process decision, a bug, an obfuscated code commit or a failing test? It is a human being. If you really want to understand the why something is the way it is, you have to connect and communicate. While there are many ways to connect these days – a face-to-face introduction without a burning requirement seems to make future communication much easier. This means try to be the first person to give.
I was very excited to see the Python wizardry at my workplace and talked to my manager if we can host the Chicago Python user group. The proposal was met with great enthusiasm and we are hosting the February Chipy meet up.
We are better when we are connected. So don’t avoid workplace White Elephant parties or potlucks.
Offer help via pairing
In an alien code base, and little domain knowledge, even if you are an
algo-wiz-design-pattern-guru, you’ll not be able to check in bugfree
code. The in-house frameworks (you have to be very lucky to have good documentation accompanying them), coding standards, testing practices
will add to the learning curve. My Scrum master realized this early,
and offered a highly effective solution from Extreme Programming.
Offer to pair with a team member on a particular story even if you
have no-clue about it. Unfortunately neither you, nor the person you
are pairing with, will anticipate that you are going to slow
him/her down. So before you start working together, its better to make
sure he/she understands how familiar you are with the language,
module, frameworks and the business problem. If possible try to read
the tests before you start pairing. Get on the driver’s seat.
Effective pair programming is HARD. Specially if you have been playing solo for a long time. You’ll feel like sharing a steering wheel while driving a
car and being forced to drive in the slowest lane. But as Uncle Bob
would say, you can only build good software by going slow.
Keep track of your progress
This is something I having picked up after I started working out (love
my fitbit and Nike+). Peter Drucker said “if you can’t measure, you
can not manage it”. Some simple metrics that you’d find immediately usable:
– # of code commits
– # of code reviews done
– increase in test coverage
– # support tickets closed
– helping others on irc, (or mailing lists)
A moleskin notebook and a pen is your best friend when you are the new
guy. Personally, I unsatisfied with only digital or only paper and use a combination of both. Additionally, have a few white sheets at your desk that
people can scribble on to explain stuff when they are at your desk.
Identify one area that needs love
Unless you are playing with the Beatles, every team has an area that
needs some love. You’ll get to learn about them during your Sprint
retrospective, which is Scrum’s way of preventing broken windows.
Make an effort to develop an expertise in those areas, and try to help
the team get more productive. A good place to start is test coverage
and writing acceptance tests.
Those are some of the tips I have received in the last few
months. They are nothing super specific to Scrum or Agile for that
matter, but helpful in an extremely dynamic environment. In the end it
is a lot of common sense and desire to help your team mates. What do