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.

Agile manifesto and principles

The text for this post is taken from the reference links. No book or blog on agile software delivery is complete without a mention of the manifesto and principles. The principles behind the agile manifesto unfortunately do not provide any in-depth insights over what is already conveyed in the manifesto. Most of the principles are applicable to any product or team, irrespective of the methodology or philosophy for execution, and this probably is the motivation and cause behind the hundreds of books and blogs that attempt to convey how the manifesto and principles have to be adopted in practice, to achieve desired outcomes.


Manifesto for agile software development (Reference: http://agilemanifesto.org/)

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

12 Principles behind agile manifesto (Reference:http://agilemanifesto.org/principles.html)

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time-scale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity—the art of maximizing the amount of work not done—is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Transitioning Product teams to agile – Key considerations

How do we enable the product team for agile product development and delivery?

 Let us first understand the links between a engineers and customers

Coder -Product Manager-Tester-IT Infrastructure-Project Manager-(execs)-Marketing-Sales-Sales Engineers-Account Managers-Product Technical Support- Customers

To enable continuous and incremental software delivery we have to navigate the above chain with maximum efficiency. (i.e. quickly and easily)

In this post I will focus on the product team (product managers and engineers). Given below are the key considerations for maximizing efficiency in delivering continuous product releases.


Engineering Team
Product delivery methodologies and tools do not deliver products; Software engineers do. The technical team needs to have the the correct composition of technical leadership, technology skills and maturity to deliver successful product releases to customer requirements and system (performance & scale) requirements, in effectively crafted product increments.
Lack of technical leadership will result in complete failure of product or releases, irrespective of the product delivery methodology of the organization.
If majority of members in the engineering team have never previously worked on software products with the level of complexity (user experience or architecture or performance & scale) expected in the product to be worked upon, it points to lack of experience and maturity in the engineering team. The engineering team might also lack experience or awareness to lean and agile engineering or collaboration practices or tools. This can result in delayed product releases through over engineering of solutions or initial optimistic commitments in a product release or inefficient collaboration and decision making during release execution.
The ability of an Organization's leadership team to effectively set-up the right engineering team is the most critical factor for the success or failure of product delivery.


Product architecture
Product architectures needs to be adequately modular to enable automated software updates to production deployments. The goal is to ensure the highest uptime for the product and a hassle free product update and maintenance experience for customers.
In the case of pure SAAS products, the organization owns and maintains product deployment in its own data centres or through PAAS providers like Amazon Web services, Rackspace or Microsoft Azure. This fact makes it relatively easier to update product production deployments with no intervention from customers.
In the case of products that either exclusively deploy in customer environments or partly deploy component in customer environments, the components deploying in customer environments have to have the architecture and capability to be able to download and deploy product updates with minimal down time and ensure minimal intervention from customers i.e. Minimize or avoid expensive product resets or restarts and consequent change management process workflows in customer environments.


Customer engagement
Engineering team have to be in a position to engage customers to get direct customer feedback on functionality being built in the product at regular intervals.

• The product team has to select a right sized and representative customer sample set to get maximum validation of product functionality being built, before the newer functionality in the product is available to all customers.
• Customers have to be able to use the product functionality being built and give concrete feedback based on their experience, at the earliest possible point in the product release cycle.
• The product has to capture the right amount of information to effectively understanding customer behaviour patterns from the customers use of the product.
• Product components deployed in customer environments and interacting with the customer environments are in a position to gather valuable information on customer environments to enable software engineers to effectively understand IT environment characteristics across customers.

Continuous Integration (CI) engineering systems
Product engineering teams have to have continuous integration engineering systems in place for continuous development, testing and delivery;

Code review tools, continuous build integration, unit testing & integration testing, software security testing, test automation, test environments, staging (production replica) environments.

The goal is to minimize the time cycle between the point at which new code is added to the point at which the new code is published to be deployed in production environments to deliver net new value to customers. As an important consideration, automation in engineering systems has to ensure that, on a day to day basis, engineers spend maximum time in writing or debugging code (creating value), and minimal time on all other activities like building, packaging, test deployments, regression tests etc.

Process & collaboration mechanisms
Information, actions and decisions have to flow effectively between every department or function involved in the value chain between the coder and customers.
Within the product team (Product Owner, and Engineering team), effective collaboration could involve daily stand-up meetings, tools for capturing arising issues (impediments), technical decisions, risks, unanticipated work items, as well as sequence diagrams,whiteboard diagrams, test results etc. that precisely convey the right state of the feature/product as implemented in an iteration on a daily basis.


Project management tools
Agile tools for tracking project scope (product backlog), iterations (sprints), regular progress on features & sub features (user stories), work that could not complete in an iteration (spillovers), in a manner highly visible and transparent to project stakeholders.


Its very typical for Organizations adopting agile to first adopt agile collaboration practices, or project management tools in isolation, to claim success at adopting agile product delivery. As a first step such an Organization would first request development managers, testing managers or project managers to undergo agile or scrum master trainings, define a new process around agile collaboration mechanisms, perhaps invite an agile coach as a consultant, and quickly get to adopting agile in the next release. This is a classic top down or management driven approach that adds tremendous burden on engineers. They have to continue with existing engineering practices, or product architectures or customer engagement practices, and now have to additionally take on additional complexity of a new process, take responsibility to be self organizing and share updates on their progress through the newer tools etc.


Agile speaks of the need for the engineering team to be self organizing. This very principle requires the organization to, as a first step, empower the engineers and technical leaders and involve them and ideally have them decide the best path to moving to an agile product delivery model. This might in-turn require bringing in upfront training to engineers on agile product delivery model to have them understand the benefits and implications of agile. This is the true agile and empowered approach to adopting agile in an engineering organization.

What is agile software development?

The literal meaning of the word  Agile - Ability to move quickly and easily.

Agile software development is a philosophy for delivering software to customers in a continuous and incremental manner.

What does continuous amount to, in practice?

It could be any interval from 1 day ( defect fix ) to one week (an enhancement) to a month (new feature) to 3 months (multiple features) or anything in between or more in extreme cases.
What do we mean by incremental? A software increment of value to customers. (Minimal viable product, a new feature or a new enhancement or a defect fix).

Agile software development can be adopted for all forms of software products. Be it a mobile application or e-commerce website or an enterprise software as a service (SAAS) product or a product that only deploys in enterprise customer IT environments.

There is no such thing as an agile software development team in isolation. True agile software development and delivery requires engineers and everyone in between engineers and customers to adopt an agile approach in serving customers. i.e. The entire organization has to adopt the agile philosophy.

To transition to agile, the organization has to absolutely clear on this simple and critical outcome of agile: Continuous and incremental delivery. The team has to then work backwards, and determine the systems, teams & business processes that need to be put in place to complete the transition.

Agile methodology can itself be adopted in an agile manner.

Agile methodology is most effectively adopted using a top down approach; from leaderdship to every ground level team member in every function; engineering, product management, marketing or sales.

Agile methodology is most effectively adopted from right to left in the value chain from engineer to customer; From customer facing functions back to the internal functions or departments and engineering teams.

Traditional businesses have been using the agile philosophy for setting up and running businesses for ages. Lets consider an example

You are an expert at baking cakes and have decided to build a business around it.You could initially start by testing your concepts with your family & friends, then identify a restaurant that is willing to add your cakes to their dessert menu. If your cakes are well received, you could then decide to extend your production capabilities to scale to a few more restaurants. At some point you might decide to setup your own outlet... and so on.

With the advancement, growth and commoditization of technology and connectivity, the software industry now has the same opportunity.

Here is an example of an continuous iterative technology product delivery to customers.
Lets consider businesses like MagicBricks.com or Housing,com which host websites to enable customers to rent or purchase apartments.

Once the business idea is validated, the first product deliverable can be the minimal capability required for owners to register and publish apartments available on rent, and seekers to register and express interest in taking up an apartment on rent, and exchange contact information with apartment owners to engage and go through with the transaction.

With this minimal product capability in place, the product can be launched in an agile and iterative manner across geographic areas, one city at a time. This approach can enable the business to focus on getting the product right in one city, and also ensure that the product (website) is not overloaded with traffic that it is not yet capable of handling. Once the product team has validated the product for a single location, it can then choose to build the right scale in the product to enable it to take on higher traffic and handle larger data sets in the backend systems. It is now in a position to rapidly iterate and expand across geographic locations.

As a second iteration, the product team can then go on build product capabilities for enabling customers to purchase new apartments and work with builders to register new projects and enable customers to discover apartments that match their needs.

At every stage of continuous engagement with customers (builders as well apartment seekers), the product team can use the opportunity to listen and take feedack from customers to continuously refine the product experience for the customer to get it to be as intutive as possible.

The product team can continue to add more capabilities to the product that continually add value to customers, and help the product and business in staying ahead of the competition.

This is too obvious an example and you dont have to be a software engineering professional to understand it. Agile software development is all about the art of making technology & software development transparent to the business or customers or shareholders. The organization should only have to focus on what value it has to deliver to customers, and software delivery systems, processes and teams should enable effective delivery of required capabilities in an continuous and incremental manner.

The transition of a traditional technology company or a technology enabled company from traditional product delivery mechanisms to agile product delivery can be challenging, but  tremendously rewarding for customers, organization and engineers.