Plan for Change - What the Customer really needs | NetEngine

Plan for Change - What the Customer really needs

Bruce Tuesday, 1 October 2013

Customers generally know what business problem they want solved but are unsure of the software solutions available to solve it. In fact, the most effective time for customers to define their roadmap is once they’ve had real experience of a working solution.

As software consultants, it’s our obligation to preserve the ability of the product to react to new opportunities. So how do we plan for this inevitable, but healthy change in requirements?

Listen to the customer

Developers must understand the long term and immediate business logic needs well enough to, at any point in time, make the appropriate technical decisions. By listening to what the customer needs the software to do, a solutions architect can sketch in pencil what the long term solution might look like, but only use pen to draw out the first small piece.

A complex system that works is invariably found to have evolved from a simple system that worked.

Start simple, and keep it simple

One of the philosophies that’s proven itself most often in my experience in software development is better known as Gall’s Law: ‘A complex system that works is invariably found to have evolved from a simple system that worked.’ It is this strong belief, grounded in a decade of hard and often costly experience, that sees NetEngine always encourage doing the simplest thing first and adding functionality later. This philosophy is one of the pillars of the agile methodology that saw us find renewed enthusiasm for writing beautiful, functional and extensible software a few years ago.

Steer via small iterations

Lean and agile thinking allows us to reduce the cost of changes in requirements by planning for and embracing change via smaller development and feedback iterations. I have yet to see an unchanged set of requirements, so we acknowledge the reality and embrace the opportunity to introduce improvements through change by planning and architecting for it.

By regularly shipping live features and functionality that create and show actual business value, the customer gains confidence in us and the methodology. We need to ship working features early on, and then quickly make evident the benefits of continuous improvement via continuous deployment.

Drive with tests

In the absence of automated tests, continuous deployment is not possible and we lose the ability to regularly release features. Testing and development have grown synonymous and quality should be the key responsibility of the developer. Writing test driven software is fundamental to planning for change, and we believe that software’s ability to change is the most important measure of its quality, and therefore its success.

Don’t Negotiate on quality

Technical debt is the cost, time and effort of changing software, and like some 'aid’ loans to Africa, has such a high interest rate that it eventually cripples the borrower (or the software). Technical debt can be avoided not only through automated testing during development but through a constant striving towards simplicity. Architectural simplicity effectively reduces the amount of tests that need to be written.

So, if quality (simply architected, tested code) is compromised during software development, particularly early on when quality’s value isn’t as evident, then one day the cost of making changes to the software will outweigh the value of that software. If quality isn’t negotiable, what is?

Understand the Constraints

An agile initiative is doomed to fail if all three key constraints of the 'iron triangle’; scope, schedule and cost, have been identified as the project’s goals. Normally it isn’t one group of stakeholders who prioritise all three, but it’s management pushing the schedule, the finance people pushing for cost and the end user the scope. There are unfortunately tradeoffs between more, cheaper and faster, and further vertices to consider, particularly in agile software development.

For agile teams, Jim Highsmith proposed the 'agile’ triangle. He suggested that agile teams should focus on the releasable product rather than implemented scope, and therefore of utmost importance to stakeholders are the new vertices of value and quality. The three traditional iron triangle constraints collapse into one vertex - simply labelled 'constraints’.

  1. Value – to the customer in terms of current releasable product.
  2. Quality – continuous delivery of value to the customer in terms of reliable, adaptable product.
  3. Constraints - the traditional scope, schedule, and cost.

It’s much better to have fuzzy measures of really important things than precise measures of less important things.

Measure for the long term

In any software development project spanning multiple phases and months, it’s actually 'quality’ that that will work in the favour of all three of the 'iron’ triangle constraints, despite appearing to work against them very early on.

Software sticks around a lot longer than the teams working on them, and it therefore needs to be measured for the longer term - on things like usability and flexibility. Business-driven quality measures are often ignored with more attention being paid to comparative measures with other development teams such as hourly rate. As Jim Highsmith said “It’s much better to have fuzzy measures of really important things than precise measures of less important things.”

comments powered by Disqus