Why we do internal demos mid sprint

 

At Twiga, we have regular demos of features in progress, most times way before the feature is expected to be finished. Now, these events are not for the weak, a fair number of times the flow being demonstrated simply tanks with a 500 error or worse.

Even if it doesn’t and you go through the happy case, everyone else in the team digs into what you have presented looking for edge cases, bugs and any other opportunities for improvement.

It is not a Kumbaya event yet I feel these sessions have helped us improve our products while cutting down on development time.

In this entry, we will be looking at why you may want to hold such critical sessions within your own teams.

Change is hard when the product is deemed complete

Typically, at the end of the sprint, what is delivered is a coded, tested and usable piece of software. Let’s use a simple project to illustrate this effect.

Imagine if you set out to clean your house, you decided you will fully clean out each room before moving to the next one. However, it’s your wife who gets to judge if the room is truly clean. After you have finished cleaning up the study and your brain is flooded with dopamine, would this be the opportune time for her to come point out all the spots you missed?

Will you be able to continue cleaning out say the kitchen while at the same time working on the spots missed in the study?

In this case, just like in software, it’s much better to have spots pointed out while you are in action rather than when you are done.

Mistakes don’t compound

Early on in one of our time-sensitive projects, we decided to switch the language used from Java to Go. Our senior team was working on this project so this switch was not anticipated to be much of a problem.

By the first demo, we noticed things were going horribly wrong, whilst the team was learning, our existing Java libraries did not play as well as anticipated with Go.

Given the sensitivity to the deadline, we decided to revert back to Java and implement a less time-sensitive project on Go.

If we didn’t have this chance to reevaluate our decisions, we probably would have missed the deadline and worse, so much work would have been done on Go we would have no other option but to commit finishing the feature using it.

Decisions are more inclusive

Over the course of development, developers make hundreds if not thousands of decisions. This is ok, after all, that is why we hire people smarter than us. The challenge is by the end of the sprint, the decision is embedded so deep in the product, it’s hard to know there was a decision made at all.

An example would be the choice of which cache provider to use, typically this decision will be made by the developer. It is possible that someone else in another team has experience with the same service and knows it doesn’t work as well with our architecture in certain use cases.

By getting this feedback early on, course-correction is possible and everyone learns something.

In conclusion, these sessions should be safe spaces. As much as possible avoid involving the client or senior management who demand perfection. To understand why. Take a tour of a garage and see what a vehicle looks while it’s being painted. Unless you are in the profession yourself, all you will see is ugliness, only other developers will be able to capture the vision being presented and provide useful feedback.

Do you hold internal demos in your own organization?  Talk to me in the comment section below or on my twitter @jchex

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Published by

jchencha

API Engineer