Development Team Membership : Part 3 – Competition

There is a thin line between healthy and unhealthy competition.  Competition can lead to self-improvement, which is great, but it can also be detrimental.  Slow down, ask yourself a few questions:

Who are you competing against?

Competition in the Animal Kingdom is a natural instinct, see tongue in cheek Lion King example.  Competition to be King helped no one in this instance.  As humans we may feel pushed to tackle those ahead of us in whatever hierarchy situation we may find ourselves in, but we’ve also been blessed with the presence of mind to make a more informed decision about how this will impact those around us.  In a team situation Collaboration normally trumps Competition.

What are you competing for and how?

It’s worth getting clear what it is you are competing for, this will be clear in a race where you have defined parameters and a clear understanding of the rules.  The same is not true of the workplace where you may be competing (silently) against other people for a promotion.  It’s easy for this situation to become unhealthy competition.  An unhealthy way to approach this is to belittle others achievements in order to make your own more pronounced.  Best case here is that you get the promotion, but your new “team” will know what you did to get there.  Impressing through your own abilities, and respect for others is a more noble route to the same thing, there’s no real shortcuts here.  It’s good to point out your own successes, but don’t try to tread on others, again, see Lion King.

Does anyone win in your Competition?

Competition can be a catalyst for self improvement, if you’ve picked the what and the how well.

Who can write the most lines of code in a sprint?

Imagine this competition, what are you really achieving?  No one wins in a headbutt!

Team Dynamic

Motivation is really closely linked to Competition in many ways, but it can also be a bit of a minefield when it comes to competition within teams.  Everyone has their own goals, but it’s great if these personal goals can align with the goals of the wider team.  I’ve previously mentioned the idea of letting go.  Losing the mental baggage that unhealthy competition carries will let you focus on bettering yourself.  I’ve recently been doing this exercise myself.

Agile : The Circuit

Ohm’s law defines the relationship between the voltage, current, and resistance in an electric circuit: i = v/r. The current is directly proportional to the voltage and inversely proportional to the resistance.

Agile from a business perspective is all about zoning in on what it is that is really required to offer the highest business benefit, in the shortest space of time, a.k.a. finding your Minimum Viable Product (MVP).

There can be a lot of ceremony in Agile, I get the impression that this is what takes the front seat in people’s minds, particularly those that would consider themselves “non-technical”.

Agile, to a Developer, should be about far more than just daily Stand-ups and Retrospectives.  Agile is a mindset and an approach, focusing on improvement, reducing your resistance.

It’s vital that any improvement you identify gets fed back into future sprints, like electrons flying round a circuit, this is what keeps the lights on.

Your backlog is your potential, like a battery, keep this topped up with ideas, both business, and technical and you will be able to run indefinitely.

Your voltage (potential difference), is what you can achieve between your two fixed points, start and end of the sprint; with your throughput, current, being everything you can potentially achieve, relative to your impedance.

As responsible Developers, we should be maximising output, and identifying and feeding back on anything that can possibly reduce our resistance.  Sure there will be no surprises here, but:

  • Improving build/deployment processes can help greatly, with DevOps as a discipline justifiably being huge business now;
  • Refactoring our code can make it more malleable and open to change, again another Agile principle, see Software Craftsmanship;
  • Scope changes mid-sprint can be a huge impact to output, this may not be fully understood by business owners, it’s important to feed this back, we would know about it if we waste their time, the opposite should also hold true (communication, and a good rapport is key here!).

Think about what you can do within your team to reduce your resistance and increase your output.  Talk it through with your peers and make a list of improvements you’d like to make, over time it’ll make your bulb glow brighter.

Development Team Membership : Part 2 – Apologies

A lot of people struggle with apologising.  It can be difficult, particularly in the workplace, but apologising even for little things can make a big difference to those around you.  Couple of really obvious examples:

Sorry, I broke the build

Sorry, I’m not going to meet this deadline

Now, it’s not likely you will need to apologise very often; in fact, if you are, it’s probably indicative of a wider issue. In the above examples, maybe you need some coaching on TDD from peers, or maybe you need to be empowered to push back on an imposed deadline.  There will be occasion, however, when things don’t quite go to plan and you just have to hold your hands up and say “Sorry”.

Apologising shows ownership and responsibility for your actions, which for me have always been key qualities with respect to choosing who I want to work with.  Those with “Teflon Shoulders” tend not to last very long.  It also shows a respect for your peers, they will know you dropped the ball, denying it will do you no favours in the long run and a prompt apology can make all the difference in getting people on side to help with a resolution if needs be.

What is an apology?

To me, an apology has very little to do with what it is being apologised for.

What’s done is done, no point crying over spilled milk, and so on.

In fact, in my head, I’ve probably already moved on…

Time Travel
Time Travel

So, what is it?

To me, an apology is:

  • a contract of intent not to make the same mistake again;
  • a display of ownership of your actions;
  • respect.

Not apologising, is the opposite:

  • a contract of intent to make the same mistake again;
  • shirking ownership of your actions;
  • disrespectful.

Sincerity

An insincere apology is worse than no apology, if you don’t mean it, don’t say it.

Closing Thoughts

It’s rarely too late to apologise, (especially if you still have a job!).  Apologising can help you get something off your chest and also have a profound impact on those around you and the way they act towards you.

Is there anything you’ve done and shrugged off into the Ether?

Next time you do something a little bit questionable, at work or outside (we all do, don’t deny it), apologise and see where it gets you.

 

Development Team Membership : Part 1 – Moaning

I recently made the transition from Permanent Employment to the world of IT Contracting.  Along with this change, came a different role for me with my new client; a much more hands on position writing a lot more code which is exactly where I wanted to be!

I previously wrote a series of Blog Posts providing tips for Development Team Leadership, this has dried up of late due to my change in circumstance, however I would like to now start sharing some tips for Development Team Membership, having worked on both sides of the fence.

Don’t moan without a resolution

Moaning is great.  Everyone loves a good moan, myself included.  Moaning can be helpful and healthy, in fact indirectly it’s part of the agile feedback loop, what went well, what didn’t.  Accompanying this, should always be next steps; how to negate what grievances you may have.

There’s definitely a right time and a place for moaning sharing your observations in the context of your team, you’ll be best placed to know when this is, but it may typically be a team retrospective, a workshop on where your team is heading or a one on one, planned or impromptu session with your mentor/lead.

As a software professional, keep it impersonal.  You won’t want to come across as a bully, picking out specific people’s faults or shortcomings is never helpful.  Code reviews should be used to increase code quality, but be cognisant of their feelings and how you may be perceived.

Mr Muscle, loves the jobs you hate

You can’t always have the glamorous roles in the team, sometimes you just need to roll up your sleeves and get stuck in.  As a good team player you should have no qualms in doing the grunt work.  Grunt work leads to insight, and insight can lead to improvement in process.  Developers are lazy, and that’s no bad thing.  Do something once, do something twice and automate.

Don't skip Leg Day
Don’t skip Leg Day

Don’t shy away from hard work.

Improvements Log

You’re the one with the low level knowledge of your application(s), any potential improvements that don’t fit within the confines of the piece you’re working on should be logged, to be addressed at an appropriate time.

This will serve to broaden the teams understanding of how they should all be writing software, e.g. coding standards/patterns, and, in the same way that code reviews serve to manage quality going in to an application.  Improvements serve to keep the application up to date.  As soon as it’s committed, code becomes legacy, it’s a valuable resource and an opportunity to improve, it, and yourself as time passes.

An improvements log can serve as a satisfying alternative to a good rant.  Log it and move on, your lead should be monitoring the situation and pushing things forward.

Development Team Leadership First Steps : Part 12

Bugs

Despite what your boss might like to think, Bugs are a fact of Software.  There’s a number of things you can do to minimise the occurrence, the severity and the impact bugs might have, mostly centring around having a reliable set of Unit Tests.  Regardless of your best efforts, they will still find a way through the net, it’s how you handle them that matters.

Be Honest

My first piece of advice would be to be honest about them, and the root cause, however embarrassing to you or your team it might be.  It’ll be too late to cover it up, so don’t waste your time thinking of excuses.  Get to the root cause and come up with a plan to resolve it.  If it’s a major problem in Production it’ll be on your shoulders to come up with a strategy to expedite a resolution. Continue reading “Development Team Leadership First Steps : Part 12”

Development Team Leadership First Steps : Part 11

I recently read The Software Craftsman, as mentioned in the review, one of the areas that struck a chord with me was the viewpoint on Legacy Code.  I deal with a lot of Legacy Code in my day job, I’ll share a few of my own thoughts and experiences on the matter.

Legacy Code – Respect

It’s important to treat Legacy Code with Respect, from all angles.  Treat it with respect regardless of how poorly some of the code may have been written, or how antiquated the technology may now be.

Continue reading “Development Team Leadership First Steps : Part 11”

Review : The Software Craftsman by Sandro Mancuso

The term Software Craftsmanship seems to be rather divisive in its support, with, as mentioned in the book numerous times (along with retorts) the fact that the movement can come across as elitist.  At it’s core it’s another manifesto, a fairly open-ended one at that, but having read the book it extends far beyond this.

In much the same way as Agile, in the pure sense, is more of a mindset than a prescriptive set of rules, the ideas behind Software Craftsmanship conveyed in the book really lean towards achieving excellence, building on and complementing a lot of the practices outlined under XP and Agile.

The Software Craftsman

Continue reading “Review : The Software Craftsman by Sandro Mancuso”