Working software or working solution?

If there are any words that describe Agile’s ultimate goal, they are surely ‘working software’.

As the Agile Principles themselves put it:

“Working software is the primary measure of progress.”

Not that all software development methodologies aren’t aiming at the same thing. But Agile is unique on keeping the focus on the end result, and not allowing itself to be distracted by formalities such as contracts, plans, specifications, procedures and status reports. The timescales on which Agile operates – software finalised, if not actually deployed, every 2-4 weeks – also makes it easy to focus on actual delivery. After all, delivery is any day now – quite the opposite of the long-term delivery schedules of so many traditional delivery projects, where the first delivery might not be until the year after next!

But is working software really the right focus? For a single iteration involving a single software development team it looks fine, but how many deliveries are limited to small upgrades, localised changes and generally things that demand no more authority or expertise that already lies within the average software development team and its established Extended Team?

What is a working solution?

For example, only if a change to existing software is pretty limited will there need to be no change to training or operational controls or database tables the Core Team don’t own or…

As for a complete new product, the list of items that need to be delivered over and above the actual software can be huge, with individual items that have positively strategic significance:

  • Changes to business policy, vision and strategy.
  • Business plans, sales and marketing components, new recruitment, etc.
  • New or revised business processes, data, standards, procedures, tools, templates, reporting, metrics, etc.
  • User recruitment, training, organisation, evaluation, etc.
  • Changed or complete new IT systems and architecture, management systems, data, etc.
  • Revised operational design; scheduling, tools and controls; skills, knowledge, training and documentation; organisation and resourcing, etc.

Plainly this goes far beyond ‘working software’! Of course, a new product like this stands at the extreme opposite from updating a single web page, and a lot of a new product is typically developed in the form of tranches of software. But still, aren’t most ‘software’ developments typically embedded in something larger and more diverse? So taking working software are your end-point suggests a far-from-optimal, if not somewhat timid process.

Impact on the Agile delivery process

So what does moving ‘working software’ to ‘working solution’ imply for Agile? Well, it places a range of new demands on the delivery process as a whole.

DemandImpact
Product management structure
  • A true product management structure will be indispensable, to ensure that all the elements of any given release are fully aligned and integrated.
  • A Product Vision, Backlog and Plan will become key elements of the process as a whole.
  • These elements will become active reference points even for iteration-level and software-only developments. This creates new issues for monitoring progress even at the lowest level.
  • Defining these elements will require inputs and decision-making from higher-level and more varied stakeholders, above the level of the Product Owner for a software-only release.
  • This is likely to create problems if successive levels of backlog – product, release and iteration – come to be managed by different groups, or so many groups are involved that the process becomes unwieldy – i.e., the opposite of Agile.
  • Agile techniques such as Story Mapping will acquire a new focus and significance, and perhaps need substantial refinement.
Backlog
  • Backlog items will typically include items that have both software and non-software implications.
  • Interpreting such a backlog – i.e., just being able to say what each item means – will be a complex multi-disciplinary task.
  • Translating these into stories (and certainly epics) into software-only stories will be harder, if not intrinsically questionable.
  • Estimation and prioritisation will:
    • require inputs from a wide range of specialists from your Extended Team.
    • introduce new forms of uncertainty.
    • be less stable as a wider range of factors across the entire product environment come into play.
    • require especially expert and considered Backlog Refinement.
Release management
  • Individual releases will contain a complex mixture of software and non-software deliverables.
  • Release and Iteration Planning will demand input and decisions from a wider group of experts.
  • Assuming that the typical team size remains in the normal Agile range – 7 or so – it’s likely that the overall release process will involve iterations with no software content and no software developers.
  • Some changes may have implications for systems, business and management architectures, with impacts on other business areas.
  • Software and non-software stories and deliverables will need to be kept aligned constantly – a potentially complex and dynamic cross-iteration, multi-disciplinary process.
  • Aligning disparate and mixed teams – defining and agreeing on what progress means and what progress has really be achieved – will be more complex than for software alone.
Team organisation
  • Release Leads will need a wider range of skills, experience and contacts.
  • Leads will need a much broader comfort zone.
  • Release teams will:
    • include a much wider selection of skills than for a pure software development.
    • be significantly larger.
  • Where substantial changes are being made, the team members are likely to include much more senior members of the organisation as a whole.
    • This may seriously affect team dynamics, decision-making and the team’s discretion to define how it works.
  • Your Extended Team will need to cover a correspondingly wider range, including:
    • different forms of technical and managerial support.
    • higher levels of authority.
  • If you do not work in a wholly Agile organisation, parts of your Extended Team – and many of your key stakeholders – will:
    • work in non-Agile environments.
    • be accustomed to a non-Agile culture and ways of working and have radically different expectations:
      • from the delivery team.
      • from each other.
      • from Agile.
    • bring a on- (or even anti-) Agile approach.
  • So basic Agile disciplines will be more difficult to achieve.
    • Collaboration and collocation will be extremely difficult.
    • Any attempt at continuous integration above the level of software will hamper smooth development.
Release packages
  • Complex releases will be the norm, demanding far more complex verification and deployment processes, skills, resources, timescales, support, etc. than a software-only release.
  • Many types of deliverable will need to be deployed at the same time, potentially including new or updated policies, business processes, user training and tools, operational processes, controls, skills, etc; reporting, integration with multiple live systems, and so on.
  • Release will need to be aligned with external events dictated by business strategies, marketing plans, related operational changes, etc.
  • Multiple iterations will need to be completed before any release is realistically possible.
    • This will put limits on release strategies based on continuous deployment.
  • Executing these releases will take more active and integrated management of many more disparate elements.
  • Your Definition of Done will be very different (both at the level of some iterations and for the release as a whole), more extensive and many of its elements will be very unfamiliar to the members of specifically software iterations.
  • Cross-iteration integration will need to take place before release is possible.

Conclusion

This is by no means the full extent of the impact of working in terms of working solutions rather than working software. Depending on your organisation, it could be better or worse, but it will certainly be different, and almost certainly harder.

And crucially, it’s not just a matter of scale: complexity is an independent variable here, so ‘Agile-only-more-so’ is not the answer.

[Warning! Pretentious analogy alert!]

So, what does all this mean? It’s like the difference between Newtonian and Einsteinian models of gravity: Newton’s equations are valid for certain limited (but still extremely wide-ranging conditions, but once you start to come close to the speed of light, Newton turns out to be not so much wrong as simply a special case of broader set of equations – Einstein’s. Likewise, working software is a locally useful but more generally limited version of what the delivery ‘equation’ should been about, namely working solutions.

The original principle wouldn’t have been harmed by replacing ‘working software’ with ‘working solution’, and it would have been more sustainable, though it would also have required some more thought about exactly how Agile fits into the corporate world. Given the historical conditions in which Scrum and then Agile first emerged – a world of massive, failing programmes – it isn’t surprising that their authors strove so hard not only to humanise the delivery process but also to strip delivery back to its basics. Nevertheless, if we continue to insist on defining working software as ‘the primary measure of progress’, then we effective resign Agile to small ballparks and minor league status.

But even this isn’t the final word on Agile’s goals. A working solution as such is no doubt a better goal than simply working software. But it still isn’t as good – and as directly tied to your organisation’s truly ultimate aims – as delivering value. But that’s another issue – which you can read about here.

By |2018-06-20T19:53:58+00:00Friday, February 9 2018|Categories: Agile, All, Business and IT, Change, Continuous deployment, Implementation, Process and method, Stakeholders|0 Comments

About the Author:

Chief Architect, Agile201.com.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.