Learning from Project Retrospectives



Grio has adapted the Agile methodology to our consulting business; and one of our most valued “ceremonies” is the retrospective. We keep these meetings open to all, and the notes from these meetings are in a shared folder for everyone at Grio to read.

Despite having access, I found them “gathering dust” so to speak, and decided to dig through the entire folder to track Grio’s ability to implement the changes proposed and avoid the pitfalls of previous projects. We’re genuinely asking ourselves, “Are we serious about learning from mistakes?”

I’ve explored the overall process of my research here, and have presented the findings in depth to our entire team. There’s some good news, and some work to do; but we’re happy to see that our efforts have created tangible benefits to our team, our clients, and our bottom line.

We’re asking ourselves:

“Are we serious about learning from mistakes?”


The Magic of Agile and the Design Process


Over the past year, I’ve been working as the solo designer embedded in a team of mostly developers and one project manager designing web experiences and publishing software for one of our clients, Rivals.com. We follow an agile methodology and work hard to effectively and efficiently integrate design. This blog post breaks down the major phases of our process and illustrates, at a high level, the role of design throughout.

Project Management Best Practices at Grio


At Grio, it has always been our philosophy that we don’t have a “one-size fits all” approach to project management. Different projects have different goals, so our process needs to be adaptable.  Some clients will come to us with existing processes that we can fit into, whereas other clients maybe be starting from scratch on their project with no processes in place and are looking to us for guidance.  Many clients are somewhere in the middle.

Release Practices at Grio


In a previous blog post, I covered the “textbook” definition of continuous integration, along with a handful of tools and practices that fulfill or help to fulfill said definition. These tools and practices include breaking up your app into components (e.g. front-end and back-end, or, for much larger projects, using microservices), utilizing “watch” utilities locally to iteratively run tests, and choosing test-oriented frameworks (e.g. Rails, Django, Grails, etc.). However, I didn’t talk much about any specific continuous integration setup, nor some of the third-party services that go together to make an efficient release process. I also didn’t talk much about how continuous integration fits into the larger cycle of deployment and release management. I aim to cover some of those topics here, and fill in the larger picture of how CI helps to ensure code quality and stability in a software project.

Keeping an Eye on Code Knowledge


In growing companies, as software systems become complex and extensively engineered, maintenance can be a challenging problem. Moreover, when high profile bugs arise and/or a lack of system availability arises, it can have disruptive consequences on a business. Hence there is little room for mistakes in these crucial systems.

Intro to Software Methodologies


Software Engineering is about more than just writing code. It is a complex process that has a lot of moving parts. Requirements gathering, planning, testing, deployment and source control management are just a few of the pieces to the software engineering puzzle. So how do we manage all this complexity? Software methodologies come to the rescue.

Keep Your App on the Rails with BDD – Part 1


A common way to describe requirements on Agile projects is through the use of user story mapping, and, as a result, user stories. This post will not cover this process, but rather the process of taking an existing set of user stories and leveraging them within our development workflow to ensure that an application is built as accurately and efficiently as possible. To this effect, we will set up tools (Rails, RSpec, Capybara, FactoryGirl, and Guard, to be precise) for implementing our app using behavior-driven development. Structuring our app in this way gives us much better odds of producing robust, low-defect code that delivers on the requirements we set out to build.

Git Merge Workflow on Github


How to Merge Code

Below is a guide that I wrote for a recent project explaining a git merge workflow on Github. Often times, when you develop a new feature, you will create a new branch off of master called a feature branch. On the feature branch, you might have many commits to save your progress, or when you complete certain milestones of that feature. Once you finish the feature, you will want to merge this branch back to the master branch. However, you might not want all your commits to show up in the git log history because they were only for development purposes. We can overcome this issue by using a feature of git called interactive rebasing which allows you to squash certain commits and customize the commits that will eventually show up once the branch is merged to master. I have described the steps to achieve this outcome below.

Table of Contents


This guide explains how to develop and commit your code using git and GitHub. A developer should create a feature branch when developing new code. In the feature branch, a developer may commit multiple times during development including making changes based on comments from a code review. When development is completed and the feature branch is ready to be merged in to the master branch, the developer should squash the commits in to one, so that the git log history is kept clean.

Unit vs. Acceptance Testing (Part 2)


By now, my post on unit tests influenced you so much that now you have 100% unit test coverage. But yet, some functional bugs still creep in and you still get the dreaded “It’s a bug because you didn’t build what I wanted” bug.

So let’s take a look at acceptance tests and how they can you help you improve your external quality and your compliance with product requirements.

We Heart Trello


Agile project management software. Neat little colored digital cards moving left to right. To do, in progress, done. Backlogs, teams, and burndown charts. Flurries of emails – sometimes useful, sometimes not, often routed to folders and never read.

Up until recently, most of us made exclusive use of feature rich tools like Jira, Pivotal Tracker, or Assembla. If you are a developer, tester, pm, or stakeholder in today’s world, you probably still use one of these tools every day. In fact, you are probably so familiar with your particular task management tool that it seems like a natural extension of your work. A job doesn’t feel done until it’s corresponding card is marked, reassigned, and/or dragged and dropped.