I suspect most of us working in IT today use agile methodologies such as Kanban, Scrum and Safe. We also strive to keep up to date with the latest developments in languages, libraries, patterns, architectures etc.

All of this is with the intent of improving the delivery speed, quality, efficiency, maintainability and the cost effectiveness of the systems we build – oh, and whilst improving our CVs at the same time.

Care though is needed to ensure we don’t get distracted by these tools from delivering the solutions they were employed for. This often isn’t through any specific fault with the methods and tools themselves but how we set about using them. 

There can often be a blinkered tendency to maniacally focus on the tools and methods themselves and in doing so fail to deliver most effectively on actual requirements and customer needs. If all you have is a hammer then everything looks like a nail.

Worse still, the job can become about servicing the tools used to do the work rather than the product of the work itself.

Furthermore these tools are often barely distinguishable from each other and for most use cases it doesn’t much matter if you use one or another; Java or .NET, AWS or GCP, Scrum or Kanban. Use what works for your team and be the master of tools, not a slave to them.

The product of your creativity is that which you build, value is derived from how your customers use the product.

Focus on the product and value it gives to your customers. Produce working solutions first and foremost – functionally and non-functionally – as efficiently as can be.

Over time we learn new methods and tools that improve delivery and optimise value for the customer but we need always be mindful that tools and methods are only a means to an end and not an end in themselves.

A Years Worth

A few Christmases ago I was messing about creating bubble maps – no doubt in some mince pie and port induced state of inebriation (quality of code is consequently as you’d expect).

I’d long forgotten about this until Kent Becks recent post on about trying to understand A Year’s Worth of effort.

This looked familiar and so with a little manipulation here’s a simple utility to convert priority ordered stories into a visual bubble map.

Waterfall v Agile v Reckless

I was recently asked when I would use an agile instead of waterfall methodology to which I don’t think I gave a very good answer at the time. These things tend to dwell in the mind; in this case at 3am!, and though thoughts at such a hour aren’t necessarily too be trusted, here goes.

“Quality, time, cost – pick any two”, is an often quoted project management notion which I’ll not go in to. A similar triplet can be used to identify which methodology to choose – functionality, time and cost.

The idea goes like this – you can prioritise any two of functionality, time or cost and doing so will tell you which method to use:

Prioritise functionality & cost over time – use waterfall. You know what you want so you can plan it all out up-front, minimise technical-debt, reduce redundancy and keep costs down. It may though be that it takes longer than you really want before you see anything go live. Good for fixed-price work, anything where the scope is well defined and time is less of a concern and some package implementations (package customisation to be avoided (as a general rule!)).

Prioritise cost & time over functionality – use agile. You want something out there soon, at minimal initial cost (think MVP) and can limit the functionality that’s delivered within these time/cost constraints. You can define short delivery cycles, size these accordingly and constrain the functionality that gets delivered within them. Good for T&M projects and anything where the vision/scope or requirement priorities are less clear or subject to change – i.e. most projects.

Prioritise functionality & time over cost – use the reckless approach. This essentially says you don’t give a damn about the money but you want it all and you want it now! If you ever hear a customer claim “money is no object!” run away. Ok, there are a handful of cases; usually government and compliance projects, where this happens but these projects are rare and typically indicative of failings elsewhere in an organisation. In all other cases the customer has frankly lost the plot. Essentially the reckless approach is one where you start trying to deliver all the functionality ASAP without much concern for anything else. You will likely throw out a lot of testing, ignore non-functional requirements, use whatever tools are to hand; whether they’re right for the job or not, and ignore any corporate processes/procedures and standards on the way. Hell, it can work! But most often it leads to unforeseen costs late in projects, excessive rework and; if you do go live with it, a lot of tech-debt and long-term costs which needs to be paid back.

It’s just unfortunate that the reckless approach is used so often when it should be so rare. It’s also unfortunate that those that deliver reckless projects often get promoted (they delivered on-time) without the long term cost being fully understood – a corollary with the quarterly focus issues many large corporations suffer.

So agile should be most common, then waterfall, then reckless. I’d also suggest waterfall should be used sparingly as there’s a tendency for the project to disappear into dark-room for many months before resurfacing and being “not what I wanted” due to poor requirements definition and lack of a good feedback loop. Agile keeps the customer much more engaged on a day-to-day basis which provides that feedback loop and minimises such waste.

It should also be noted that neither agile or waterfall say anything about the work-products needed to deliver them. They don’t say “don’t do requirements definition”, “don’t do design” or “don’t test”, far from it, they just do it in different ways (user-stories v consolidated requirements definition for example). You also need to have an understanding of the long term vision, scope and dependencies within an agile project to avoid excessive tech-debt; or at least be conscious of the implications of short term decisions. From an architectural perspective you still need to identify the building blocks, do the design (logical and physical), establish non-functionals, identify key decisions and dependencies etc. But whilst you may go into all the detail up-front in waterfall you can spread this out in agile with a relatively shallow but broad scope solution outline up-front (essentially identifying the key building blocks and non-functionals) and go into depth as and when needed. To believe you can avoid such work is to make assumptions and to; consciously or otherwise, adopt the reckless approach…