Distributed Teams, Part 6: Workflow & Feedback Loop

Now that we have set up the basis for a distributed organization, it’s time to get to work!

Takeaways:

1. Cyclicity, agency and autonomy are the cornerstones of effective workflow.
2. Use Agile sprints to implement cyclicity.
3. Choose an appropriate feedback loop period.

Ride Development Cycles Like a Bicycle

Establishing efficient workflow from the onset of a project is crucial for achieving the best results. There are three core principles of a productive workflow: agency, autonomy and cyclicity. We’ve already discussed agency in part 3. Now let’s talk about the other two.

Cyclicity. A successful project requires a steady pace. Scrum methodology uses sprints, which last two to four weeks. No matter which methodology you use--Waterfall or Agile--you need to establish a universal cycle with which the team will sync their work. Scrum methodology is the most suitable for our work since it is cyclic in nature.

The ground rules for Scrum:

1. Every cycle (sprint) is assigned a predetermined scope that doesn’t change until it’s complete.
2. Every sprint must be an autonomous piece of work, with no overlapping dependencies.

The entire team begins by filling the first sprint from a prioritized product backlog. Then everyone breaks into their local teams to complete the work. After each sprint cycle, the results are merged and evaluated; code conflicts are resolved, loose ends are tied, and a new cycle begins. It is essential that employees work autonomously and free of disruption during the sprint.

Autonomy is the greatest strength of a distributed team. Jason Fried of Basecamp has written extensively on this topic. He believes that physical distance from the office or from another team is actually an advantage that boosts productivity, and prevents workers from getting distracted.

Within each sprint, local teams concentrate on the user stories they have been assigned as communication remains minimal. But as the sprint comes to an end, everyone must sync their work, merge the pieces and put together a demo to show what was accomplished and how it plays into the larger picture of the product.

Feedback Loop

If you are in a client-vendor relationship, feedback will flow continuously and will come after each delivery. The process for building a product within a tech company is similar: you show the demo to product owners and listen to their remarks.

Here’s where you might run into a problem: if you have your next sprints already planned out, processing feedback becomes inconvenient, because it will jeopardize your production plans. This is where Agile methodologies start to earn their keep, as they give you the flexibility to plan the next sprint only after the current stage is completed. This is what cyclicity is for: to track progress according to fixed expectations that are based on two-week cycles.

There are two approaches to working with feedback:

1. Set aside time to incorporate feedback in the last several sprints.
2. Immediately incorporate feedback into your next sprint.

The second approach works best for our team. This way, work goes faster, and our partners are more satisfied with our progress. The trick we use is to create smaller sprint cycles for servicing feedback. A team of a few people works exclusively on feedback from previous sprints and updates the staging server faster, which translates into exceptional customer service from our clients’ perspective. Although we always strive to make maximum progress, whether on the front-end or back-end of the process, we have observed that clients are uneasy about waiting long before seeing their input incorporated in the project. Moreover, the second approach improves our ability to correctly apply the feedback, because the context for suggested improvements is fresh in our minds.

Pro tip: never put principal developers on a feedback loop.

They should work on the “heavy lifting” and the core of the product while another group makes simple fixes.

Completing the Process

Now you have reached the end of the process, and the project is almost ready. What do you do? First, pay special attention to the QA process. During development, QA teams check every commit locally. Before merging the product, developers should conduct their automation tests. After that, the QA team should run manual and regression tests. This order is essential to ensuring that nothing slips through the cracks.

Finally, it’s time to organize the launch party! And yes, it would be great if it were a fun, face-to-face party--it’s up to you! Don’t forget that launching the final product requires several days of intensive work: acceptance testing, final regression, showing the product to the owner on a live server (or stage server, with conditions close to live), who will then make a final decision about the release. The launch is the last, vital step, and we recommend booking extra time to complete it properly.

It would be great if after the final schedule sprint everything launched flawlessly. In reality, there are almost always loose ends to tie up. There will usually be a smaller 'support' team that stays behind and observes the product in action for a set period of time.

In the next and final post in this series, we will explain how we performed all these steps with one of our clients with a tight timeline.