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, 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.

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.

Continuous Integration: An Overview


Continuous Integration at Grio

In the same way that testing code is more and more becoming table stakes for modern software projects, continuous integration is increasingly becoming standard on projects of any non-trivial degree of complexity. Here at Grio, we leverage continuous integration whenever possible, in order to eliminate time spent performing routine deployments and tracking down integration issues.

A Software Consulting Conundrum: Providing Estimates While Staying Agile


Software Estimates

As a software consulting firm, Grio strives to provide high quality, high value software to its clients. We embrace an agile software development methodology based on Scrum. This iterative approach provides our clients with flexibility to adapt and change their product over the course of development as discoveries are made while using the software.

This flexibility can prove challenging when providing up front estimates regarding project costs. The problem arises that providing an estimate that is too high may lose you the contract; Estimating too low can result in several outcomes:

Scrum is like 20th Century Politics (Part 3 of 3)


In Part 1 and Part 2, we saw the forces of extreme right and extreme left savage two organizations in the name of scrum. One company goose stepped about in Luftwaffe jumpsuits. Another built a gulag for stakeholders who would question its developers-only central planning meetings.

In both cases, malevolent propagandists diverted the team’s purpose, and product progress all but ceased. The right was called wrong. The in progress was called done.  The 1 was called 0. User stories were enigmatic and undecipherable.