Agile can be seen as an interplay between its two overarching goals of building the right thing and doing it properly. Although 'Interplay' is putting it positively, as they often compete for resources and spend much of the time far from a harmonious balance

The dominance of Scrum in the Agile landscape has perhaps had us focused too much on the left hand side of the picture. We’re slowly correcting this to appreciate the importance of the counterbalancing right.

Of course the more technically-aware have been working hard on this for many years. However, it’s still quite shocking just how few organisations have really grasped how important, and difficult, it is to build the thing right.

Such an imbalance is probably the fastest way to accumulate technical that we have yet invented.  

Helping stakeholders understand this picture enables them to appreciate the true Agile picture and the consequent levels of investment in skills, people and tools that are needed.

Luckily Agile has some very good and established patterns to ensure we can achieve this balanced state.  

Yin and Yang speaks of complimentary and interdependent forces in a dynamic system, just like those we try to work with in software development

Build the right thing..

Is achieved through a number of established Agile principles and practices. 

Get close to users and understand their real requirements

• The Product Owner role in Scrum, and its equivalents in other Agile approaches – clearly identify the person with domain knowledge who we can hold accountable for ‘what’ is built.
• Well established ways to deeply understand requirements e.g. User stories, Specification by Example or Feature Driven Development
• These both enable us to hear the ‘user’s voice’ amongst the complex hubbub of development
• Early, frequent validation of our deliverables keeps us aligned to expectations
• More telemetry and metrics of how the solution is actually used help to validate the solution provides us with the final feedback loop

Build better solutions through closer collaboration and on-going emergence

• Daily collaboration within the team and between the team and PO or users encourage emergent solutions, informed by multiple perspectives.
• We have found ways to unleash the creativity of intelligent people and tapped into the collective, focused purpose the team.

Don’t begin to develop software that is not properly understood or may become blocked

• Definition of Ready (for development) ensures we don’t start to work on requirements that we don’t understand or are too big or ambiguous.

Align overall development capacity to changing organisational priorities

• Portfolio Backlogs act to align development capacity with the organisation’s evolving priorities in a single place, transparently.

And.. the Agile Manifesto says

• “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”.
• “Business people and developers must work together daily throughout the project. “
• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Build the thing right

Summarises the technical rigour that many organisations appear either unaware of – or find too difficult to try.

Prevent bugs or find them quickly when cheaper to fix

• Test Driven Development, Continuous Integration help to prevent defects – or find them rapidly
• Cloud-like technologies mean we can finally afford to do performance testing earlier in the process

Keep focus on the code quality

• Peer review of code, clear coding standards and pair programming help to move good practices around a team and establish accountability amongst peers for the work they are doing. This is much better than trying to ‘police’ the quality by an architect or other external role
• Code quality tools like SonarQube track key trends, like complexity or maintainability, over time. Alerting us to any negative drift in the trends of complexity and maintainability.
  • If I were using outsourced teams, this would be an easy, transparent and fair way to hold them accountable for the quality of their work - and yet so few companies do this.
• Refactoring and principles of ‘internal open source’ also help to maintain the focus on code quality.

Make the solution resilient and adaptable

• It is certain that the solution will evolve over time. Well documented code, wrapped-up in automated testing is a fundamental pre-condition to that process of evolution.

Focus on finishing high quality work

• The team’s ‘Definition of Done’ and Scrum’s emphasis on shippable quality every sprint helps to embed quality in the team’s daily work.
• Slicing work up into small chunks means we get more of into the done column more frequently

Building it right, through to live

• The ability to reliably deploy the solution into live is a key part of building it right.
• The automation of testing, build, environment-creation, configuration and deployment are relatively new though already indispensable set of disciplines and capabilities.
  • All brilliantly summarised in Jez Humble’s book ‘Continuous Delivery’

And.. the Agile Manifesto says;

• “Continuous attention to technical excellence and good design enhances agility. “
• “Simplicity - the art of maximizing the amount of work not done - is essential. “
• “The best architectures, requirements, and designs emerge from self-organizing teams”.