Agile Best Practices for Product Development and Engineering Teams

1. Create structured documentation

Structured documentation serves as the single source of truth for the project execution and ensures that everyone is on the same page. This, in turn, improves team collaboration and makes the execution process more efficient.

In a LinkedIn comment, Nikita Belokopytov, Senior Engineering Manager at AutoScout24, noted, “Without a written document, one cannot adapt an idea to the circumstances—there is literally nothing set in stone. One cannot even negotiate scope or ask for more help on the project if neither the scope nor the workload is recorded. From my experience, lack of documentation for projects and decision-making breeds chaos, which in turn slows down the team and causes crunches and churn.”

Documentation can be a tedious and time-consuming task, that much is certain. To fast-track the process, start by holding a simple planning and brainstorming session with your team. Once your team is clear on what needs to be done and what the execution process is, you can write down the plan in a concise document that is easy to read. Then you should pass it around to the project’s stakeholders for full transparency.

2. Have daily standup meetings

The Scrum Guide defines daily standup meetings as 15-minute time-boxed events for development teams to plan for the next 24 hours.

Jeff Nielsen, Chief Technology Officer at Brivo, says, “The purpose of the daily standup meeting is for a team to plan and coordinate its work for that day. What are we going to do together in the next 24 hours? And what’s our plan for collaborating? Who’s going to work with whom? What’s getting worked on? What other priorities do we have, and in what order do things need to happen?”

These questions help you identify and solve any challenges your team members are facing before these roadblocks become bigger problems that can derail the project execution down the road.

Be mindful, though, that standups can become monotonous and a huge waste of time if you don’t plan them well. Here are a few tips for running effective daily standup meetings:

Make sure that the standup attendees are people who will be working together for the next 24 hours.
Set a clear goal.
Avoid trying to solve problems during the meeting. You can and should identify issues to be solved during the meeting, but only address them after the standup.
Add some variety. You can change the order of providing updates or use a different view in your Agile tool to present at the meeting.

3. Visualize your project workflows

Visualizing your project workflows gives you a clearer picture of what needs to be done, when it should be done, and who is responsible for it, so that you can plan more effectively. It’s a great way to break down large, complex projects into trackable, discrete actions.

As an individual, you’ve probably had instances where pending tasks seem overwhelming or insurmountable until you put them in your calendar or lay them out in a planning app like Trello or Asana.

Once you do that, all of a sudden it turns out that you’re able to prioritize pressing tasks, delegate the ones you won’t have time for, and set deadlines to keep yourself accountable. The same can be said for Agile teams.

Source: Asana

One of the best ways to visualize project workflows is to use a Kanban board. A Kanban board is a project management tool that allows you to map out and manage project tasks, workflows, and communication.

When you add new tasks to your Kanban board, you can:

assign them to different team members;
add start and/or due dates;
create project stages like “incomplete,” “in progress,” and “in review.”

Finally, you can move tasks through these different stages as things progress until your project is complete.

4. Have a continuous integration strategy

A continuous integration strategy allows developers to get near-immediate feedback on new code or any iterations they’ve made to an existing code system.

It prevents development teams from spending long periods of time building solutions that are no longer feasible and helps them to stay in the loop and up to date on changing user requirements. All of that makes the development process more efficient.

Jeff Nielsen explains this concept with an analogy of driving remotely on Mars. He says that even the most skilled drivers from Earth would take longer to safely move from Point A to Point B on Mars because of the speed of sending signals between Earth and Mars.

“The difference, of course, is the speed of the feedback,” says Nielsen. “On an average case, you’re talking 10 minutes to get a radio signal up from your steering wheel on Earth up to the vehicle on Mars. When you’re driving a regular car on Earth, you can see immediately what you’re looking at when you turn or when you’re putting your foot on the gas pedal, you can feel what’s going on there. The speed of the feedback affects how quickly you can drive and the speed of the feedback affects how quickly you can work in general. This applies to software development.”

Your continuous integration strategy should require developers to check their code multiple times a day, rather than waiting until everything is done. Consider setting up an automated verification system to make this process more efficient.

“The build has to run fast,” says Nielsen. “There’s a threshold beyond which people will not wait around for the build to finish. And I found that that threshold is about 10 minutes. Soon as your CI build creeps up beyond 10 minutes, people will stop checking in. They’re not going to sit around and wait for the results for more than about 10 minutes. So there’s a magic number there. You can keep it to five, even better, but the build has to run quickly for it to be valuable as a feedback mechanism.”

Other things to note as you set up your continuous integration strategy are:

The build has to be reliable. That is, it must produce accurate results all the time.
It should be difficult for anyone to ignore the system’s feedback.

Nielsen says, “Having the CI server send out emails to everyone on the team is just not sufficient. It’s too easy to ignore email or filter it into an inbox that you’re going to read later. I found things like an audible siren or some other sound that plays in the team area when a build breaks or even flashing lights that are red when a build breaks, those are the kinds of things that are much harder for people to ignore.”

5. Use burndown charts for sprints

A burndown chart is a graph that shows pending tasks and how much time is left for the completion of these tasks—whether in a particular sprint or the entire project.

Pending tasks are represented on the vertical or Y-axis of the chart and the duration of the project is placed on the horizontal or X-axis. As the pending tasks are completed, the graph “burns down” to zero on or before the last day of the sprint or project.

Source: Wikipedia

A burndown chart is a core Scrum best practice, because it provides a real-time status report on the project’s progress. This has two major advantages:

It helps you identify challenging tasks that can stall the project execution, so you can address these on time.
It makes it easier for you to know when a sprint would take more time than expected, so you can inform stakeholders in advance.

You can create a simple burndown chart in Microsoft Excel or Google Sheets. Here’s a short step-by-step guide to help you:

Fill out the time and tasks into your sheet—like we’ve done in the image below

Generate your chart; to do this, follow these steps:
- Select the “Dates,” “Planned,” and “Actual” columns
- Click on the “Insert” option in the top menu bar
- Select “Chart”
- Select any simple line chart from the options

6. Pull, don’t push

“Pull, don’t push” is an Agile 101 principle that regrettably often goes unimplemented.

In a Push system, your engineers wait for tasks to be assigned to them. But in a Pull system, they take ownership and quickly pick up tasks based on their skill set and bandwidth. This prevents micromanagement and allows tasks to get done quickly.

Marko Oksanen, CEO and Product Evangelist at Coventures.io, says, “Very few organizations have an actual Pull mechanism where the team actually decides what to take into the sprint.”

When you have a team operating within a Push environment, unaccustomed to taking business responsibility, it takes some time to switch this mindset around. One tip here is to “push softly.” This means that you start using indirect control to direct the discussions to the right stories being picked.

Oksanen says, “Even if you gently nudge them to say which ones are important, you don’t outright state that. But rather force the team to have a discussion about the premises on how stories are picked. If this doesn’t work in the beginning, then you can ask them what they would need to empower them to make these decisions by themselves.”

Final thoughts on Agile best practices for product development and engineering teams

Here’s the key insight you should take away from this article: prioritize principles over processes.

In many cases, people adopt tools and processes for their favorite Agile framework—Scrum, Kanban, Lean project management—without understanding the fundamental principles that make everything work.

Because of this, they can’t use these frameworks effectively. For example, they may use a Kanban board without work-in-progress limitation, or try to combine Waterfall planning with Scrum processes.

If you want to truly win with Agile, invest time into teaching your team the core principles of any framework you adopt—that’s the only way to succeed.

Thank you for reading our article! We hope you found it useful. If you did, be sure to check out these other resources on our blog to learn more about Agile and Scrum:

Over the years, we’ve helped several of our clients increase their business value and boost the performance of their teams by introducing them to the Scrum methodology and teaching their developers how to work Agile.

One of those clients was Evalueserve, who were so satisfied with the changes we suggested to their workflow that they named 2020, the year we started working together the closest, their “best year ever for product innovation.” Jeroen Kleinhoven, Head of Digital Products at Evalueserve, even had this to say:

“I think the most value was the rigor of the use of Scrum—the rigor in Agile team composition, the rigor in Scrum rituals. We came from a kind of a mixed, not that effective way; I think we’ve gained a lot in the two years we’ve collaborated with STX Next.”

Feel free to take a look at the full case study of our cooperation with Evalueserve. Does your team need similar support with being more Agile in their day-to-day work? We can help you out with that, and so much more. All you have to do is reach out to us and we’ll get right back to you!