One of the 12 principles in the Agile Manifesto is "Working software [or product] is the primary measure of progress." That's why Scrum teams rely on agile teamwork to deliver something of value to their customer every iteration.
For this to happen, agile teams embrace concurrent engineering. Concurrent engineering (or simultaneous engineering) is a way of working where tasks overlap, rather than happening in a series of phased handoffs.
The Main Benefit of Concurrent Engineering
Contrast overlapping work with sequential engineering, where product development work happens in phases. For example, on a software project, we might have an analysis phase followed by a design phase followed by a coding phase and ultimately a testing phase. At the end of each phase, work is handed off to the next person or team with the skills to complete the next phase of work.
If that happened on an agile software development project, it might take 4 iterations before a team could deliver something to the customer!
So cross-functional agile teams instead collaborate to complete all activities necessary to deliver a product increment inside a time-bound iteration (sometimes called a sprint). The various kinds of work overlap.
Using the previous example, on a Scrum team, as one developer is designing a user interface, a second team member begins coding the functionality, and a third developer begins to create tests for the functionality. All inside the same iteration!
At the end of the iteration, high-performing agile teams are able to deliver a fully conceptualized, designed, created, and tested increment of value to their customer.
Concurrent engineering speeds up product development and time to market–not because teams are working faster or harder, but because they are able to get small chunks of completed functionality into the hands of their users sooner. This gives organizations a tremendous competitive advantage, and is one of the many reasons companies adopt an agile methodology to begin with.
To make concurrent engineering work, agile teams must do three things: Avoid finish-to-start relationships, embrace uncertainty, and start separately but finish together.
Avoid Finish-to-Start Project Management Practices
When some teams first begin implementing agile, they cling to their sequential mindset and finish-to-start activities with a series of activity-focused sprints. They use one iteration for analysis and design, a second for coding, and a third for testing. The team is split in thirds, with the analysts working one sprint ahead of the programmers and the testers working one sprint behind them.
This can be a very alluring approach for teams who are new to agile or Scrum. Not only does it seemingly solve the problem of how to overlap work but it also allows each type of specialist to work mostly with others of their own kind, which many are used to doing.
Unfortunately, the same disadvantages apply to activity-specific sprints as apply to activity-specific teams: too many hand-offs and a lack of whole-team responsibility.
Activity-specific sprints create what are known as finish-to-start relationships. In a finish-to-start relationship, one task must finish before the next can start.
For example, a Gantt chart on a sequential project may show that analysis must finish before coding can start and that coding must finish before testing can start.
Experienced agile teams learn that this is not true; many activities can be overlapped.
In agile projects what is important is not when tasks start but when they finish. Coding cannot finish until analysis finishes and testing cannot finish until coding finishes. These are known as finish-to-finish relationships.
Embrace Uncertainty
To start a task while a related task is not yet finished, the team needs to become willing to work around uncertainty and open issues temporarily.
The key thing for team members to understand is that while they eventually need an answer to those issues, they do not always need the answer before starting work on a product backlog item. Instead, they can share enough information (for example at the daily scrum) for other team members to get started.
As an example, suppose a team is working on a user story, “As a user, I am logged out after n minutes of inactivity.”
Before that story can be considered complete, someone is going to need to decide how long n is--30 minutes? 12 hours? But, someone could absolutely begin work on that story without the answer.
Once team members fully grasp that some answers can be learned during the iteration, they become much more willing to live with the uncertainty that is needed to practice the overlapping work of concurrent engineering.
This is an iterative and incremental approach to project management: Get a few details from the users about what they need and then build a little of it; build a little and then test what you’ve built.
The goal should be to start the sprint with just enough information that the team can barely finish each product backlog item. Team members should feel that if they had to resolve even one more open issue during the sprint, they could not have finished that product backlog item.
Start Separately But Finish Together
Some people argue that to maintain a holistic point of view, certain activities (e.g., user experience design, database design, and architecture) must happen upfront.
I argue that we should think holistically but work iteratively. One way to do that is to stagger when certain activities start.
With an agile approach to work, it doesn’t so much matter when each team member starts on a product backlog item. What matters is that they all finish together, or as close to it as practical. In a 10-day iteration, one team member may start coding a user story on day six and another begins creating tests on day eight. Their goal, however, is to finish together on day ten.
I equate this to running a race around a 400-meter track as in the Olympics. Because outside lanes are progressively longer, runners in those lanes begin the race further ahead physically on the track. This ensures that each person runs the same distance and that they finish at the same place, making it possible to judge the winner.
An agile team can think of certain specialists (analysts, graphic designers, product designers) being in the outside tracks in the development process. They need a bit of a head start. (Yes, I know in a real running race everyone starts running at the same time. But the starting line for the outside track is “ahead” of the inside track.)
The analyst needs to identify what’s even being built. And the designer may need to provide wireframes, mockups or similar starting points to the team if the team is to have any chance to build and test the feature within a sprint. So giving them a bit of a head start by having them look ahead towards the work of the next iteration is a good idea.
Note that I said "a bit of a head start." The designer does not work apart from the team or work three sprints ahead. The designer is absolutely on the team and the designer’s primary responsibility is helping the team in any way possible to finish the committed work of the current sprint. They just leave enough capacity to look ahead to the next sprint.
A good product owner does the same thing. A team is in trouble if the product owner is so buried by the work of the current sprint that the product owner arrives at the next sprint planning meeting without having given any thought to what to work on next.
Certain roles on an agile team need to be looking somewhat ahead. They should look ahead only as far as necessary, but some peering forward by product owners, analysts, or designers is helpful.
