One of Substantial’s constants is experimentation. Very few practices are considered sacred and we’re constantly implementing new ideas as team members come up with hypotheses about how to write better code, design a better experience, or deliver products faster. We recently finished up a project where we tweaked our delivery process and I wanted to share some of the things we experimented with and what we learned.
Prefer Face-To-Face Communication
We started this project by getting all team members from Substantial and the client together in a face-to-face meeting. Attendees included project stakeholders, UI/UX designers, software developers, and a product manager. The goal of this meeting was to get everyone on the same page with respect to what the project was about, its timeline, and engagement strategy.
This type of meeting happens at the beginning of every project; what made this unique was the presence of all members of the implementation team. Often times, only a few representatives are available to attend and a game of telephone has to be played to disseminate all of the learned information. Getting everyone in the room together allowed all those involved to start with the same context and as a result, we were able to jump in and start building right away. From this early date, team members were able to form relationships and put names to faces, which proved valuable as the project matured over time.
Keep the Backlog Small
The first activity of any of our projects is to define the work that we’re going to do. This definition is captured in the form of user stories. Stories are placed into a product backlog where they can be prioritized against each other as needs change. When a new feature is requested, we create stories for that work and add them to the backlog at the appropriate priority. Anytime we need work to do, we pull a story from the top of the backlog.
Backlogs can get long and unwieldy as new user stories get added over the life of a project. Often times, the team will never get to many of these stories because of time or money constraints or priority calls. Inevitably, these stories just end up being noise in the project tracking tool.
On this project, we decided to try to keep our backlog to a minimum and only create stories for features that were going to be worked on over the next 1 to 2 weeks. This “just-in-time” story writing had a couple of advantages:
The client could take a look at our project tracking tool (Trello in this case) and easily see what we were working on now and what we’d be doing in the near term.
It became obvious that everything that was in our short backlog was going to actually get worked on. Anything we decided wasn’t important enough to work on was removed from the backlog.
It was easy for team members to see and react to what was coming up. Our teams are composed of personnel from different disciplines and not all team members work at the same pace. So it becomes advantageous to be able to see just a little down the road without getting overwhelmed.
Like getting down to Inbox Zero, it was emotionally satisfying to see stories get completed and see an end to the list.
Getting to the end of the backlog meant we needed to create more stories. This gave us time to get together as a team and figure out what we wanted to do next and how we were going to tackle it. It also gave us a nice point to pause and take a step back to see what we had done and how it fit into the application as a whole.
It’s a common desire to put any new idea or feature request into the backlog so that the idea doesn’t get “lost” or forgotten. Many times these backlog items are either so ill defined or so low priority that there’s very little chance of them ever getting worked on.
We tried to eliminate as many of these stories as possible from the backlog and when we couldn’t (i.e. when it was important to a team member or client), we would place them in the Nice To Have (NTH) bucket. During those pause points between features or when we had a free moment or two, team members could pull from the NTH bucket. Taking time in the process to put a pause on strict feature delivery and do smaller, sometimes less MVP-worthy tasks was incredibly satisfying for the team and ended up being a way to boost morale.
The Pomodoro Technique is a way to break down the time it takes to do work into smaller intervals. A small break is taken between each interval, giving an opportunity to step away from the problem at hand. Many Substantialites do this at the individual or pair level; our team decided to try it at the team level. We all agreed to work on a story for 25 minutes and when the 25 minutes was up, we would all get together to check in with each other. These check-ins ended up being sort of like a mini-standup, where we would give updates on what we were doing or get help with anything that was blocking us from completing the story.
A big win for doing team pomodoros was that everyone always knew what the other team members were doing and if someone needed help, we could immediately add or switch up pairs to more effectively solve the problem at hand. It also had the effect of limiting the amount of time that got spent micro-focusing on some problem at the expense of the rest of the feature (sometimes called rabbit holing). We didn’t follow the Pomodoro Technique strictly; we only chose to use the time-boxing feature of it and even then, didn’t always stick to 25 minute intervals all of the time. Still, in the end we realized that the act of doing constant full-team check-ins allowed us to move faster and react to challenges as they arose.
Substantial’s delivery process leans heavily on elements of Lean and Kanban, favoring experimentation and embracing change. A few of us had been thinking about making changes like those above or had done smaller versions of these types of experiments in the past and felt that the time was right to try them out on a larger scale. Because our process lends itself to modification, some of these changes happened naturally, emerging over the course of the project.
Our team saw lots of success from the obvious changes (getting everyone together at the same time at project kickoff and keeping a small backlog) and the not-so-obvious changes (having ten mini-standups in a day). Some teams at Substantial have already implemented some of these changes and future projects will benefit from the lessons we’ve learned here. Substantial’s is a culture that benefits from this type of experimentation and we’ll continue to refine, iterate, and try out new things to deliver awesome products for our clients.
Any questions about our experiments? Let us know in the comments!
Greg is a lead developer at Substantial. Greg is also a very nice human being.
Main image from Flickr user alpha du centaure.