# Friday, 03 June 2016

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

yinyang

 

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.
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”.


.
Tags: Agile | Kanban | Lean

Friday, 03 June 2016 16:39:00 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Friday, 23 November 2012

The simplest illustration of the benefits of focus must be this one – clearly illustrating that if we focus on _and finish_ one feature (or project) at a time then all 3 features are delivered quicker.

Agile emphasises delivering value sooner – in order to generate revenue, create lessons and validate assumptions.

clip_image002

  1. In the ‘current situation’ all three features are started as soon as they are requested – but none are finished until near the end.
  2. Focusing on one at a time means that A and B are delivered value sooner in the second example
  3. However, many studies (e.g. in Tom DeMarco and Tim Lister’s book ‘PeopleWare’) show that there is a real cost in switching between tasks.
    Therefore, assuming a saving of only 10% – we see that all three features are delivered significantly sooner. This is not just a marginal gain, it could translate into weeks of additional sales.

As well as the benefit of earlier value and lessons – don’t underestimate the energising effect on a team that delivering A, and knowing it’s in the hands of users, can bring. Focus increases the ‘realness’ of the work and sense of achievement and recognition that the team.

Focus also means more collaboration within the team, which can only bring a better solution – creatively built from multiple perspectives.

The intuitive assumption is that the sooner we start something the sooner we finish it…

… the real challenge is how to adjust the behaviour that’s driven by this assumption, which often recurs at every level of the organisation.

.

Tags: Kanban | Lean | Visualising Agile

Friday, 23 November 2012 11:32:04 (GMT Standard Time, UTC+00:00)  #    Comments [0]


# Thursday, 01 November 2012

The delivery pipeline is an idea which resonates with our clients. The simplicity of the metaphor and the truths that it reveals make it a compelling message to share with others in the organisation.

The pipeline helps to visualise two key Lean principles; seeing the end-to-end value stream and ‘optimising the whole’ http://bit.ly/ImpLean It illustrates the emerging emphasis on Continuous delivery’ http://bit.ly/CDAgile

The overall organisational aim is to balance the pipeline, as any constrictions generate waste.

The pipeline helps with the key challenge of getting senior stakeholders to prioritise and budget the money, and time, to balance the pipeline end-to-end.

clip_image002

Instinctively, because developers create functionality then, if we want more functionality, we must need more developers. Whilst jarringly simplistic, this is a perspective held by too many senior stakeholders.

However, adding more developers or teams, immediately leads to an imbalance in the capacity of each section. More development teams develop more code, which we then try to force through the lower environments – where it sits, wastefully, in queues or trying to muscle its way past other projects waiting for a limited slot in a integration test environment.

clip_image004

In addition to the waste, the quality plummets due to the stress of trying to get work through this constriction. A situation that is often made worse when these downstream environments are shared with other projects / programmes.

Similar constraints usually exist upstream of the developers. The Product Owner role is new to most businesses and the level of on-going work they need to do is often underestimated. Beyond the responsibility for preparing stories every sprint, collaborating with the team on a daily basis, POs need to actively engage with stakeholders and users.

The diagram below illustrates the actual capacity of the pipeline, which can be quite an attention grabber. It’s troubling for senior stakeholders to realise they are paying for all that under-utilised development capacity.

clip_image006

 

Steps to a balanced pipeline

Step 1: Communicate the need of optimising the system end-to-end

Use the pipeline diagram to communicate the essence of the challenge. These issues are difficult for even IT people to see and understand, even though they live with the stress of these systemic shortcomings on a daily basis. Create a sense of urgency by providing estimates of how much this waste is costing, both in money and in delayed value to customers.

Step 2: Prioritise and target specific interventions at the points where they will have most impact


clip_image008

  • Investment in the environments, automated testing and deployment tools to ensure frequent/continuous movement of software through the environments to live
  • Improve the quality and frequency of collaboration across traditional organisational boundaries, e.g. between developers, service introduction, support and infrastructure.
  • Improve ways of working upstream between Product Owners, stakeholders and the teams. A clear vision with stable portfolio backlog is more likely to create a steady flow of high priority work into the development teams.
  • The teams themselves can improve quality and throughput by adopting Agile/XP technical practices and working more closely with both the product owners and the ‘downstream’ teams.

Step 3: Visualise the waste with a value stream map

Visualisation and quantifying of the waste is key to building a sense of urgency for change and then targeting interventions at the most wasteful sections of the pipeline.

Value stream mapping is the simplest and most effective way to identify where the biggest queues and worst bottlenecks are in the system. The best resources on value stream maps are Mary Poppendieck’s books, including Implementing Lean Software Development’ http://bit.ly/ImpLean

Real-time visualisation of queues is best done with Kanban techniques, which can highlight emerging issues in the system.

Step 4: Get senior stakeholder support and the budget and time

The level of investment needed in environments and tools are often new to a business, which may not be clear on the sizeable returns available. These returns are often in the form of reduced waste, which many senior stakeholders can’t see or evaluate – even though they can sense waste all around.

A senior director estimated that 50% of their software development expense was wasted. How have we ended up accepting, or not able to deal with, this level of waste?

A smoother flowing pipeline also reduces cycle time, meaning that profit-generating functionality is deployed sooner.

Whilst getting the budget is difficult enough, ensuring the work actually gets done, month after month, is even harder, given the prevailing culture in many businesses.

Businesses and managers are rewarded for delivering value to customers. Few businesses reward managers for improving the capability of their system to deliver value.

It’s common to recognise the sacrifice in fixing problems – rather than rewarding those who prevented the problems in the first place.

The ‘non-functional’ work needed to improve system capability is difficult to value and prioritise in any company-wide backlog of work. Those that understand the potential benefits of a balanced pipeline need to articulate that value and be prepared to be held accountable for delivering the promised benefits.

This cultural bias, towards delivery and not improving the means to deliver, continually sabotages attempts to balance the pipeline.

Step 5: Expect resistance and be in it for the long haul

The value stream maps highlight that many constrictions occur at existing boundaries within the organisation. The delay, hand-offs, lack of visibility and accountability at those boundaries are the biggest challenge to creating a balanced pipe.

These changes to what people do, how they work with others, changes to accountability and their daily work will generate resistance.

Specific action is the best way to ignite the change. People on both sides of the boundary typically suffer from its existence and are often keen to improve the situation.

And… it’s not just the pipeline… but the shape of what you put down it..

In addition to working on the pipe itself – the throughput will be significantly improved by looking at the material going through it. This is the subject of a follow-up blog, where we’ll look at batch size, variance and work-in-progress as key variables.

In the meantime, Mary Poppendieck already has some good insights on this at http://bit.ly/LeanPipe

.


Thursday, 01 November 2012 15:31:00 (GMT Standard Time, UTC+00:00)  #    Comments [0]