Agile Working for Productive Development

Engineers and business people alike are enthusiastic about the benefits of creating an agile workplace. Not only is communication improved, and transparency increased, but the ability to produce and iterate on products in a cleaner and more efficient manner can also come out of this work approach. If you’re not familiar with agile in the workplace, you may want to take a course like An Introduction to Agile to learn what agile is how it can work for your company.

If you’re considering adopting agile for your work environment for your engineers, it’s important to understand why people would be attracted to this way of working. In many engineering companies, agile is becoming the norm, but it hasn’t been that way forever. Older approaches such as waterfall development have typically provided engineers up front with complex and detailed product requirement documents, which they then went off and developed in isolation. In an agile environments, product owners and engineers work closely together to refine and develop the features of the product as it is being developed.

Getting product owners and engineers working more closely together can feel odd at first. Often these professionals work in independent ways, and aren’t used to communicating with each other in the same style. However, the advantages of having a shared work approach that integrates the needs and expectations of both can be a huge advantage.

To consider whether an agile approach might be right for your organization, it can be useful to think about how the day breaks down for a typical worker in an agile environment. As an example, let’s take an organization that has adopted scrum, One of the most popular and well-documented approaches to agile working. You can learn more about scrum from a course like this Introduction to Scrum and Agile.

In a scrum organization, projects are broken down into individual user stories, each one of which describes a feature that can be completed within a timeframe called sprint. A sprint typically last from 2 to 4 weeks, and is considered to be the period of time necessary to develop a new feature from concept to final delivery. Creating the user stories is the responsibility of the product owners, but everybody who works on the project has a chance to vote on the effort involved in completing the story at sprint planning meetings, which happen at the beginning of each sprint.

Once the stories for a sprint have been defined, and the effort involved in each has been voted on by the team, a typical day for an engineer will start with a daily stand-up meeting. These 15 minute meetings give every engineer on the team a chance to talk about what they did the previous day, what they’re planning to do today, and whether there are any blockers preventing them from moving forward. These meetings are limited to 15 minutes, and are usually done standing up to prevent people from going off onto tangents. Typically, a scrum master will manage the meeting to make sure it stays on track. You take a course like this one on the role of the scrum master to learn more about this important function.

After the daily stand-up, engineers select stories from the backlog for the sprint based on their priority, and start working on them. In many companies, engineers work in pairs rather than individually. Often these pairs will rotate, so that knowledge of the entire codebase is gradually shared across the entire engineering team, rather than being locked in one person’s head. Pair programming also improves the quality of the code generated, and has been shown to increase productivity across the course of the workday.

Regardless of whether the engineers work in pairs or individually, the user stories and their order in the backlog guide the work being done. A properly groomed backlog may be adjusted by the product manager during a sprint to make sure priorities continued to align with the needs of the product owner. While the engineers are working on the stories for one sprint, the product owner remains available to the team to help clarify and define any issues that might not have been cleared up during the sprint planning meeting. At the same time, the product owner is developing stories for the next sprint, so that they will be ready for the next sprint planning meeting.

Over the course of the sprint, each story goes through developments, testing, delivery to the product owner, acceptance, and actual deployment to the customer. Each story should be a complete feature that can be delivered to the customer within the scope one sprint. If any story seems too big to deliver as a completed feature within one sprint, it needs to be broken down into manageable stories before the sprint planning meeting, or as a result of the conversations at the sprint planning meeting.

Evaluating the effectiveness of an agile workflow in scrum is based on the points of effort assigned to each story. The team as a whole votes on the number of points of effort necessary to complete a given story. Points have no relationship to hours or days worked. They are an abstract metric that varies from team to team. After a series of sprints, it’s possible to track the velocity of the team by seeing how many points effort they can expected to complete within a single sprint. There are courses specifically designed to teach you how to measure the effectiveness of your scrum.

Working in an agile way enforces certain disciplines on both the product owner and on the developers. For product owners, the discipline is not making any changes to the requirements or the user stories during the course of a single sprint. If stories truly need to be changed before sprint is done, the sprint needs to be restarted, and a new sprint planning meeting held. For engineers, the discipline of agile working is the transparency of sharing progress at standups and potentially working in pairs rather than as individuals.

An agile approach allows companies to produce more effectively. if you want to learn more there are great courses you can take that can teach you how to get over the impediments to using agile in your company.