At 4-Ti we decided to take a hard look at our development process and see how we could improve as an organization. One of our goals with this planning was to standardize our development process so that no matter how many projects, customers, and developers we have, we will consistently create high-quality products.

We did this in a few ways. The first step was to define the development process and then to figure out how we can best act on that definition. The team discussed a few different interpretations, but we agreed as a team to define “development process” as The process of transforming a requirement into a deliverable.

Great! Now we have the definition...so what is the next step?

photo by Jeff Stapleton

We ended up having a series of meetings about the agile process and how we can better ourselves as a team and individual developers to follow the agile methodology. One of the first assignments given to junior members of the team was to review the Agile Manifesto in preparation for group discussions on the topic.

As a team, we broke down the development process into four steps- Planning, Implementation, Testing, and Deployment. With these steps in mind, we structured time to discuss each step and how it relates to agile development and our work as an organization.

Let’s dive into the highlights and takeaways from each step.

Planning

Our general approach is to take requirements and write stories that contain acceptance criteria and a plan of how to implement the requirement. In our conversation about planning, we talked about the pros and cons of different approaches and how stories can sometimes become entangled in one another. This is obviously not desirable, and neither is going into a planning meeting with stories that are not clearly defined. 

Our solution was to commit to two-week sprints and midway through the sprint to have a refinement meeting so there was time to get clarification on any stories well ahead of the next planning meeting. So now, at the beginning of a sprint, we have a backlog of well-formed and clear stories and halfway through the sprint, we have a refinement meeting looking at upcoming requirements for the next sprint. 

This continuous cycle of planning and refinement had rapid effects on the team and we all noticed smoother collaboration in our work.

Implementation

A few interesting topics came up when discussing implementation. This includes the reusability, and readability of code that is developed, and how we review our team member’s code.

Having simple code that is reusable and easy to understand is the goal of many development teams, but this does not always happen when you are fulfilling complicated requirements.

Having components and code blocks that are sharable is usually advantageous, but we agreed that this should be decided in the planning phase.

We also agreed that a significant way to help the team develop smoother and faster is to make it a priority to review and run another team member’s code that is ready to be tested and provide feedback as quickly as possible.

Testing

We have automated unit tests in all of our projects, but we how do we truly follow the Agile Manifesto and ensure that we are satisfying “...the customer through early and continuous delivery of valuable software.”

We took a hard look at our current working style and decided we as a team needed to test more often and more thoroughly on our dedicated test environment. Not all dev teams have this available, but once we committed to testing each requirement on our production testing environment, very quickly we saw our customers complimenting us on a job well done, and there were fewer issues and bugs reported. 

Deployment

One issue we identified was our deployment frequency. We decided it was best to deploy more frequently...essentially deploying one story at a time. This deployment into our production testing environment allows our team to test requirements in multiple environments, and also identify bugs and side effects of deployments much more easily compared to deploying a batch of requirements all at once.

Our first go of this went remarkably well...even with a bug involved! We isolated an issue after it was deployed, created a “hot fix” and within 20 minutes the patch was implemented and it really showed us the value of testing on multiple environments and the benefits of deploying at a high frequency.

To conclude, we recognized that there was room for improvement and growth in our development process and we committed to taking steps to help better serve our customers and grow as a team and individual contributors.