Tag Archives: agile

posted

October 9, 2017

Learning from Project Retrospectives

by

Overview

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?”

 

read on

posted

April 26, 2017

The Magic of Agile and the Design Process

by

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.

read on

posted

November 11, 2016

Project Management Best Practices at Grio

by

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.

read on

posted

August 18, 2016

Design & Development in Tandem

by

I had the privilege of attending this year’s San Francisco Smashing Conference in early April where I listened to presentations from founders, designers, and front-end developers.

Smashing Magazine is a fantastic online resource for professional designers and developers. They also publish their own books and e-books, as well as host conferences in the U.S. and Europe.

read on

posted

June 7, 2016

Release Practices at Grio

by

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.

read on

posted

September 10, 2015

Intro to Software Methodologies

by

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.

read on

posted

August 19, 2015

Keep Your App on the Rails with BDD – Part 1

by

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.

read on

posted

December 2, 2014

Continuous Integration: An Overview

by

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.

read on

posted

November 20, 2012

A Software Consulting Conundrum: Providing Estimates While Staying Agile

by

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:

read on

posted

January 24, 2012

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

by

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.

read on