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 11

Fear-Of-The-Dark.jpg

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.

TheSoftwareCraftsman.jpg
The Software Craftsman

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