Software is Best Demonstrated, Not Explained

The relationship between software product teams and business stakeholders is fundamentally broken in our industry. Business stakeholders seldom have the visibility they need to evaluate the productivity of their teams and those teams struggle to communicate it. Building software doesn’t have to live in a constant state of being over budget and out of time. Progress and timelines don’t have to be a mystery. I’ve spent the last 10 years as a software engineering consultant working with teams at small, medium, and large enterprise companies. It’s a prolific and acute problem. The simple practice of demoing working software is one of the most powerful ceremonies organizations can adopt to build trust and drive understanding. 

An emphasis on working software is not a new concept, it’s a core principle in the original agile manifesto:

“Working software is the primary measure of progress.”

It’s the most important, and yet, it’s the first one to get buried behind all the other ceremony that has bloated “agile software development.” When myself and Austin Vance started Focused Labs, we wanted to ensure that all of our teams follow a practice of demoing working software at the end of each week. Shipping code is the ultimate goal. Demos are also the most powerful way to reshape the relationship between the business units that fund software and the teams that write software. It is the single most important ceremony for software product teams to hold themselves accountable to.

So why is demonstrating working software so hard, and why don’t we see it more often? Well, strong demo practice is the culmination of a highly functioning software product team. It requires that the product being built has direction, purpose, and a sense of priority. It requires planning ceremonies that are efficient with succinct backlogs. It requires that there is a concise and demonstrable definition of done. It means that developers have confidence in their code and introduce change with ease. In essence, it means that your agile process actually works. That’s not common in the software development industry. Demos are a forcing function to get there.

Let’s define “working software”

A common definition is important here. Many teams miss the “working” part of working software. Without adhering to this definition of working, demos devolve into just another status meeting.

Working software is:

• Functional: It provides a capability as is. It is something that could be provided to an end-user in production and they would get utility out of it. 
• Integrated: The software is not on some repository branch or fork of the product. The code is working alongside all the other code in the product.
• Available: The software product team doesn’t have special access to the software. Stakeholders and humans outside of the team can access each and every feature that a team demos.

Don’t confuse working software with finished software. The software does not have to be finished in order for it to be working or demonstrable. Let’s look at a simple example.

A team is building login functionality for a new application. The business knows that it wants:

1. Users to be able to create a new account based on their email address
2. Login with Social SSO (Google, Twitter, Facebook, Microsoft, etc…) 

Most teams would tackle the login feature described above as a single unit of work. It would not be considered finished or demonstrable until users could either create a new account with their email address or opt to login with one of the Social SSO options. Inevitably, the team realizes there is a 3rd point of complexity:

3. Users who previously created an account via email should be able to merge a Social SSO login with their existing account.

Now, new scope has been introduced, estimation of effort is inaccurate, the feature is still not finished, and nothing has been demonstrated. Despite having just described three distinct states of working software, most teams would think about and demo it as one. Teams that force themselves to demo working software regularly every week will need to tackle work in smaller, more discrete units.

1. Week 1, Demo 1: New users are able to create a new account and login via their email.
2. Week 2, Demo 2: New users are now able to optionally sign up via a Social SSO.
3. Week 3, Demo 3: Users who previously created an account with the email can opt to change their login to a Social SSO login.

A login feature that only allows users to sign up with their email address is working software even if the Social login option is never completed. By building and demonstrating the login feature in this way the team minimizes WIP (work in progress) and provides the option of abandoning #2 and/or #3 from above because the software is already in a working state. If we extrapolate this example and think more broadly about how software projects typically go, this is the crux of the problem. Teams try to build too much at once, unvalidated scope inevitably creeps in, and stakeholders are asked to bear through delays and setbacks. A promised “big reveal” rightfully leads to skepticism. Consistent and continuous momentum is a much easier foundation to build trust. Trust erodes when a team only communicates about progress in terms of burndown charts, high-level roadmaps, or stoplight-colored status reports. Progress needs to be measured by the amount of working software produced!

A strong and consistent demo practice will…

Create alignment and solicit feedback: There is immense power in showing iterative working software week after week. The standard response from stakeholders is a stronger sense of understanding and ownership. The team is consulting stakeholders rather than just informing them of status. They become a part of the conversation about what the team is doing, why they are doing it, and what they should be doing next. The business is able to provide concrete feedback rather than continuously asking when it will be done.

Demystify the software itself: To many clients I have worked with the software they are responsible for is a mystery. It’s easy to conjure up an inaccurate mental model of what the software is and what it does when it is not in front of you regularly. Early demo sessions tend to reveal a lot of surprises: “Oh, I didn’t realize that wasn’t an automated process” or “Wait, we don't track that data on a per-user basis already?”. By pulling the individuals responsible for budgeting and funding the software into the actual development process, they are better able to manage risk and are more informed about their investments.

Make the hard conversations easier: Demonstrating software changes every week reshapes the conversation when things go wrong. By keeping the feedback loop tight, going down the wrong path is kept to a minimum. When an integration turns out to be more challenging than initially anticipated or data that was presumed to exist actually doesn’t, it’s addressed earlier rather than later. Small mistakes don’t spiral into big ones, which is very taxing on the relationship and erodes trust.

Drive more agility into teams and process: As we saw in the example above, a team that demos every week must have small discrete stories that leave the software in a working state. This percolates into all aspects of the SDLC. Backlogs become more targeted, the definition of done becomes crisper, retrospectives have a more meaningful impact on improving process, and software gets shipped more frequently.

How To Get Started

At Focused Labs our teams follow these steps to establish a regular practice of demoing working software on a weekly basis: 

1. Schedule: The first step is to schedule them. Actually put them on the calendar! We don’t wait until we are in a “good spot to start demos”.
2. Lobby sponsors and stakeholders: Ensuring that all parties understand why demos are important is key to their consistent attendance and participation. We want stakeholders to be engaged and supportive of this practice. Havin them work with the team and celebrate wins goes a long way to making the practice stick.
3. Prepare: Demos take preparation. Having slides to frame the narrative and tell a continuous story is important. The Product Manager typically articulates this narrative and frames what the objective for the week was and how it went. A reminder of the elevator pitch for the product every week is strongly encouraged. 
4. Demo the working software: Put the slides down and the software up via screen share. Make sure that links and login access are readily available to your audience. Walk through completed changes for that week and talk about them in terms of what problems they solve for users and what value they bring to the business.
5. Take Questions, Ask for Feedback: Make sure you field questions, solicit feedback, and address comments throughout. 
6. Share What’s Coming Next: Make sure you talk about what the plan is for the following week and how learnings from this current week are playing into next steps.
7. Be Consistent: Do it every week and always find a way to demo working software even if the changes are minimal.

Go forth and demo working software! If you are interested in learning more about Focused Labs or our approach to delivering working software drop us a line!