James sits on a stool in a darkened room, a TV is behind him and an iPad is in his hands. Around him are two semicircles of interested stakeholders sitting on chairs. It’s an intimate setting, conversational, and one that allows him to see the reactions and responses from those in attendance. The crowd riff of each other. James says the moment that sticks with him the most is when the realisation sets in: their product is becoming real. The tired and over-complicated process is being chipped away.
James’ showcase is similar to the many other showcases run around the planet with engaged stakeholders. It’s the journey to the showcase that was different. Showcase driven development is not about the next iteration, or a list of features or stories, it’s about the next time we sit in front of those people, our users and potential users. The product owner attends the showcase, gauges how it went, and decides who we should showcase to next and what work is needed to impress them. It’s part collaboration, and part internal marketing.
With the showcase set for a week away, it’s time for the team to conduct their collaborative design sessions. This is where the magic lies. Whiteboards are cleaned, marker pens strewn around, and they start to explore the user flow. Refinements come as the person gets more comfortable with how creative and open they can be. After 30 minutes to an hour, the product owner pops in for some chit-chat with the users and takes them for a drink of water. The interviewer or their partner in crime will capture the whiteboard musings and create a POP app from it all. On their return, the users can play with an interactive prototype on an iPhone of their efforts.
He gets such a great response. The feel of the clicks and the visibility of transitions solidifies their understanding of how it will work. From this point, the users are engaged – they go on sell the product to their colleagues. James tells me they’ve been called up by their colleagues asking when they can they be involved in the next session. They’re at a point where they now have too many people wanting to be involved; quite a change from the absentee product owner situation.
“This is where the some of best feedback occurs.” says James. “We might have three drop downs and a text box and the user will try it and realise that because of where they work they can only use one hand at at time. We redesigned it to six big buttons for the most used functions.” They’re also told that there might be too many screens and they’ll collapse them.
After the collaborative design session and before the showcase the team goes about making a static version of the real application. They won’t put a backend in until it’s been through the showcase because there will be new revelations. The showcase has more people than the collaborative design session. It’s as much a feedback session as it is a showcase: “We use static pages because they’re low cost things to throw away or change.”
After the showcase they start putting in lightweight storage mechanisms. Things like local storage or in memory databases. “If we feel an aspect of the system congealing into something solid we’ll start putting in a more permanent back end, but for most of it we are not ready yet.”
The team’s philosophy came about by trying to make no irreversible decisions. “We don’t want to do anything that will potentially limit us from pivoting later.” That’s manifested as not being tied to a technology stack –they started with Ruby, ditched it for Go on the back-end and Node for asset compilation, it wasn’t a big deal to change. They also don’t use big frameworks on the client side. Their fear is that as soon as you take one on you start spending more of your time being constrained by what the framework allows you to do. “Ever notice how most Bootstrap apps look like Bootstrap, and how you can spot a Backbone app a mile away?”, says James. “Yeah, avoiding that.”
Our infrastructure is deliberately light. We have a small and mature team, and we’ve made a conscious decision to forgo many of the standard environmental fare. An example is our lack of a Continuous Integration server, we’re not integrating, and we’re small enough to just run tests before we push. Nothing is forever though, and we’re continually evaluating our need for every piece of our project and infrastructure.
We’re currently hosting on Heroku and can change that easily. For most of the project we’ve not had a database. James laughs. “That led to some difficult conversations with the internal IT department. They’d wanted us to use their standard enterprise fare of Oracle DB and when we said we didn’t have a database, they didn’t get it. How can you have an application without a database?”. The database is a great example of our evaluation approach, we need it now so now we have a database. It’s an in-memory database and local storage on the devices. Both of those will change in the future and that’s the point.
For James the moment when they realised what we were doing it the right way was when their product owner came in and said we had 2-3 days to do a massive pivot and try and sell to a new market. “We built out the prototype as fast as we could in those 3 days and pitched it. The business were ecstatic and began throwing money at us to add their features in.” He recognised it wasn’t perfect, the quality dropped and they took on some tech debt which they’ve been paying off. “I think that another team would have let such an opportunity pass them by. We seized it. Our approach let us do that.”