How to Build a Winning Agile Development Team

Categories: Agile | Software Product Development |

team_goalThere’s no question that Agile development concepts are here to stay, but just saying that a project is being done “with Agile methodologies” isn’t the same as true Agile development.  Being agile means more than just setting some sprint timelines, intermediate goals and having regular scrums. You also need to be prepared to adapt from the very beginning – and that includes deciding what the makeup of your development team will look like.

Structuring your Agile Team

There are several ways you can organize your Agile team, but before we even talk about the team members, let’s talk about how the team is structured and how that structure can change as the project evolves. During planning, you can get better results if all team members work on the same level. Instead of creating a hierarchical structure inside the team, all members can work together, meeting the needs of the project in the moment without the restrictions born from a chain of command. This leads to a higher number of ideas to help build software solutions while dealing with challenges before problems occur.

Once planning has finished and it’s time to begin creating code against the plan, you should revert back to a more managed structure to ensure that resources are being used to their best result.  Software development teams usually have various specialists, project managers, programmers, testers, user-experience experts and so forth; and with this diverse group, there are a lot of personality types involved. But with the Agile methodology and its focus on collaboration, the project’s goals remain in the forefront.

Who’s on the Agile Team?

The perfect size for an Agile team is between 5 to 10 people, which should include:

  • Programmers/Developers
  • Architecture Designers
  • User Experience Designers
  • QA Experts
  • Business Analysts
  • Managers/Leaders

But here’s the key – whose on your team can change as the project progresses. In sprints 0 and 1, where initial planning and architecture are emphasized, it’s useful to have an architect who can start designing the framework of the software. It’s natural in the beginning to have a lot of ideas and mockups. But when you start translating that into code, you may need additional architects or senior programmers to apply their knowledge to build the base of the product.

Off and Running – How far do you sprint?

Once your team members are in place, it’s important to monitor them with timed tasks to measure success. Sprints that last for a week or two can provide valuable project feedback on an ongoing basis (which means that you can more easily gauge timetables and how realistic deadlines are). Resist letting deadlines creep much past the two-week mark. A month deadline, for example, might be counter-productive, since the team could relax with a benchmark that seems relatively far away and you’ll be getting that feedback less often. Developers on a sprint should feel some modest pressure, to keep intensity up and remain accountable to the project and the client.

Remember, the very name of this methodology – Agile – is one that conveys the team is quick and nimble; able to complete the software solutions that they have been hired to deliver but also to rapidly adjust to changes and problems that may come up. By assembling the right mix of talent, structuring them properly on a team and setting the right timelines, you can do just that.

If you have questions about the best way to build an Agile team, or how to best oversee the outsourcing of software development, contact Belatrix. We can help you build an Agile development experience that’s right for you.

Leave a comment