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 Leadership : First Steps Part 8

Constructive Criticism

Something I’ve seen many people struggle with is the ability to take constructive criticism, and inversely offer it.

Giving Constructive Criticism

I’ve previously recommended being free with advice.  An extension to this, and a vital leadership skill is the ability to critique a colleague’s work without causing offence.  Obviously being rude about someone’s work will alienate them and earn you no favours, but it’s often the case that a colleague won’t quite have understood the direction in which you wanted them to head with a certain task.  There’s a couple of things personally you can take from this : Continue reading “Development Team Leadership : First Steps Part 8”

The Star Wars / Software Development Paradigm

In preparation of Star Wars Episode VII – The Force Awakens, I, like many others are watching the other 6 films.   An experience I am inflicting on, sharing with my partner with mixed success.

123 vs 456

My partner had never seen Star Wars Episodes 1, 2 and 3 (lucky her you may say, I might agree), and was actively against the idea of “wasting time” doing so.  As films in their own right, generally I could take them or leave them but I also understand the relative importance of knowing how Darth Vader came to be, and quite enjoy the completeness of watching them all in the correct order (that’s another story).

It occurred to me that in having this conversation, it was actually pretty similar to conversations I regularly find myself having at work… Continue reading “The Star Wars / Software Development Paradigm”

Development Team Leadership : First Steps Part 7

Honesty

Honesty is the best policy…

…unequivocally.  Trying to cover something up simply doesn’t work.  Everyone makes mistakes, even your boss, and if they’re worth working for, they’ll know that.

As the lead you should be the first to admit when you:

  • are not going to make a deadline;
  • did something silly that broke the build;
  • are wrong;
  • simply don’t know the answer to a question.

The last one is really important.

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

Development Team Leadership : First Steps Part 6

Pragmatism – Take your time

I’m sure you’ll have heard the saying :

Rome wasn’t built in a day…

…and it’s fair to say that 99% of the time, neither will your app be.  Be realistic regarding what you can achieve and by when.  Everything about the Agile methodology points to being able to work sustainably, and getting better at doing so along the way.  There’s many articles about picking a vertical stripe or horizontal stripes through your architecture and delivering a concise set of functionality.  My advice would be, don’t let your chosen stripe get too fat.  If you can’t hit an imposed deadline, be honest and say ‘no’.

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

Development Team Leadership : First Steps Part 5

Saying No

One of the most important skills in leadership, is knowing how and when to say ‘no’.  It might sound trivial but it’s really far from it.  There’s an excellent chapter in The Clean Coder by Uncle Bob Martin.  I was fortunate enough to read this prior to having been put in a situation where I needed to say no and I found it  invaluable in hindsight, would highly recommend.

As a fresh Lead you will no doubt have a number of challenges in managing client expectations, and at points they will inevitably ask too much of both you and your team.  It’s times like these when you will gain the respect of the client for your honesty and integrity and the gratitude of your team for not putting them in awkward situations.

It’s easy to say yes, don’t fall into that trap, but just remember there’s a right way to do it. Continue reading “Development Team Leadership : First Steps Part 5”

Development Team Leadership : First Steps Part 4

Push Yourself

Don’t be afraid to tackle situations that will push you out of your comfort zone, you’ll always be better for it.  If you’re :

  • nervous about a presentation, do it;
  • putting off an awkward conversation, have it;
  • unfamiliar with a technology, learn it.

…you get the picture.

There are of course limits, be sensible.  Start small, Rome wasn’t built in a day and so on, but each time you tackle something new your horizon has expanded slightly, you’ll be unstoppable.  Have confidence.

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