What is working software or demo-able software or valuable software?

The Agile Manifesto refers to the concept of working software.
Working software over comprehensive documentation

The Principles behind Agile Manifesto refer to the concept of working software.
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Principle 4: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time-scale.
Principle 7:Working software is the primary measure of progress.



The concept of working or demo-able or valuable software appears quite obvious and commonsensical and like all such things, can escape even the best of engineers.
Firmly imbibing an understanding of working software in a consistent manner across the entire software engineering team is the most fundamental training required, at the onset of the transition to an agile delivery mode of execution. 

Here is the most common and obvious interpretation of agile of an engineering team newly transitioning to agile (in the context of coding and delivering working software)

In response to customer requirements or problem:

• Devise a new solution and technical design to be supported in the product release.
• Create a lean design and solution and get to the implementation stage as soon as possible. Avoid documentation of solution as it is time consuming (we would rather be coding), and continuously keeping such documentation updated in response to changes is cumbersome.
• Divide the implementation phase of the feature into N parts of X weeks each, each to be called as a sprint.
• Plan for a demo at the end of every sprint to demonstrate working software to stakeholders, and incorporate any feedback in subsequent sprints.
• Meet everyday to report on progress to the team and management, raise challenges or risks early, and resolve them early in the release stage.
• Repeat each day, week and sprint to defined script as per agile, and deliver the required functionality in N sprints.
• Repeat the above process for all features that constitute the minimal viable product release for the product.

The above definition is nothing but a leaner form of waterfall delivery model morphed as an agile model of delivery.

Back in the days of c programming, when engineering teams transitioned to c++, the programming language syntax remained the same, and most engineers, jammed in c functions into class member functions, and swiftly completed the transition. True thinking to objected oriented programming principles and consequent entity models and class implementations came in much later. The transition to agile software delivery requires a similar shift in paradigm in software delivery, build around the customer.

What do we mean by working software or demo-able software or valuable software?

Valuable software is software that solves a customer problem, and is ready to be deployed in production.

How do we go about building valuable software in multiple sprints?

Agile manifesto emphases on customer collaboration. The most critical phase of this collaboration, at the beginning of a product release, is at thoroughly understanding the customer problem. The second phase, is in validating the the solution devised in the product truly solves the customer problem.

Given a product release feature, how do we decide which part of the feature is to implemented in which sprint?

In traditional models, an engineering team would build the complex database or back-end systems to eliminate technology risks as early as possible and then build the layers upwards from bottom to the top, and add the UI layer (usually seen as the least complex or risky part of the release). In most software products, the UI layer is the only layer exposed to the customer. i.e. We built software products inside out(From technology to the customer). And then made them available to the customer for download and trials.

In today's highly connected world and commoditized connectivity costs, we now have an opportunity to build and deliver software outside in. From customer, the customer problem, back to technology.

As product engineers, we have to ask ourselves the following questions.

• What is the quickest path to getting the product out to customers and users for early validation? (wait no later than you need to to confirm success)
• What input information or data do I need from customers upfront in product release cycle to test with real data inputs early in the engineering cycle as possible? (avoid simulating or guessing data or inputs when you can actually use real data to accurately test and confirm success.)

This in turn influences the team to take a top down (end to end) approach to building features in the complete product component stack, as well as in visualizing the end outcome upfront and then reverse engineering the sprint plan to get to the end outcome in the earliest possible time span.

At times, this might mean that, the architecture required to meet the performance and scale for every customer or all customers, is not yet in place in the first software increment delivered to customers.

Internally, multiple sprints might be required within a product release, to get to a stage where in valuable software is ready to be delivered to customers. Each such sprint has to produce a working software increment that is demo-able (early sprints) to customers or ready to be deployed for actual hands on use and trials by customers and users. When the team reviews a sprint plan and targeted outcomes from the customer perspective (what can I demonstrate and share with a customer at the end of each sprint to get customer feedback and to convey the progress we are making on the product release), it keeps the team honest to agile principles. Regular demo's and update to customers and internal stakeholders in-turn builds tremendous confidence amongst customers, product owner and the leadership team. Working software thus becomes the best and only measure of success.

This write-up about working software sounds pretty obvious; however you are bound to face challenges if the following is true for your team

• An untrained (in agile) team can easily get lost in technology or theoretical or paper solutions or use simulated data or worst, use limited and hand-crafted test data and deliver working code or working components as working software. 
• If the business domain for the product is complex, and the engineering team does not have the right level of maturity in the domain, they are far more likely to stick to doing what they know best (design, evaluate technology and code), as opposed to taking on the customer problem and customer solution validation phases, head on, EARLY into the product release cycle. 
• If your organization is structured by different teams owning different parts of the product stack, members of such teams are bound to only look at what work they have to do, and not worry about the overall picture. At worst, the team might expect the testers to figure out and tell them whether the solution works end to end in the product stack.
• If team members are geo-distributed they are bound to pick up the work that requires minimal interactions across teams, first, and then plan integration phases late in the game.

This is where the engineering leadership team has to set the right standard, and really review and confirm that the team indeed has put the customer, and customer problem above everything else, and has a great agile plan in place to get the product release out of the door . Great delivery strategies, that focus on early validation of understanding of customer problem and early and continuous confirmation of solution (and its completeness) with customers, is the only way to ensure successful releases. And an engineering feature or product has to delivered accordingly to such a strategy built at the beginning of the release.

Agile delivery philosophy requires engineers to put the customer problem and customer collaboration for solving the customer problem, ahead of coding and technology, and that is never intuitive to most die hard engineers passionate about technology and eager to write code and learn new technologies all the time. With agile, engineers now have to 'run their own business'; Be engaged & engage customers and product owners, and own product feature releases from start to finish of a product release.