When you’re trying to put together a development team, you want to structure that team for success. It would be great to have all the perfect team members, but that dream cannot always be realized.
Budget limitations are often a major concern. Hiring a seven-person team, like the one I outlined in another post, one that includes a software architect, senior developers, and a QA specialist can be costly.
If budget is not holding you back, maybe you are struggling to fill these roles due to limited availability of staff or other recruiting challenges. After all, it can take time and effort to find talent.
If you’re facing any constraints and you can’t put together a Super Scrum Team, you might be left feeling a little hopeless. Don’t worry, there are lots of things you can do!
Here are some tips:
- Favor generalists over specialists. Those who can do a little of everything are going to be much more valuable than putting a few highly-specialized individuals together. Even if it takes them a little longer to produce because they are not absolute experts in one area, you’ll avoid roadblocks due to over-specialization.
- Have at least two software developers. Having only one programmer is going to increase the technical risk quite a bit. There is no one to bounce ideas off of, peer-review code, and act as a backup during vacation, sick days or even getting stuck fixing a particularly nasty bug.If you only have the budget for one programmer on the team, I’ve found it’s almost always better to have two developers working 20 hours per week vs. one developer working 40 hours per week.
- Favor senior team members over more junior team members. Senior team members get stuff done, and they get it done quickly. If you have the option, create a team that favors senior software developers over junior developers or a mix of senior and junior developers.
- Favor a smaller team over a larger team. You may find yourself thinking, “If I have a few more bodies, I can get more done.” This line of thinking is only valid if you can closely match the ideal mix of Scrum team members.If you start adding team members, particularly specialists or junior technical people, they are likely to drag the team’s productivity down as they are brought up to speed. More communication is typically required. If you have time to absorb the ramp-up, this may be a sound strategy, but be careful about adding team members close to a deadline, especially if your team is already humming along.
- Don’t skimp on the product owner and ScrumMaster roles. Be careful about assuming you can eliminate one of these roles. Without a product owner to channel the needs of business stakeholders, the Scrum team is rudderless. Without a ScrumMaster to keep the level of Scrum discipline high and ensure proper communication, it’s highly likely for team members to regress into the old and unproductive habits they were practicing before Scrum, losing out on productivity gains.If you have to skimp on the product owner and/or ScrumMaster, I encourage you to keep both roles but reduce the involvement to part-time. If the team is smaller than seven, it’s likely that the product owner can spend 20 to 30 hours per week on the project and the ScrumMaster can spend as little as 15 to 25 hours per week, and keep things moving along with little impact. This setup is better than dropping one of the two roles.
One key tip: Do not combine the product owner and ScrumMaster into one person. Part of what makes Scrum work so well is the natural tension between these two roles. Have a separate product owner and ScrumMaster, even if it’s a part-time role for each.
How does this work in practice?
We recently had a software development client who wanted to take us for a test drive to see what we could produce with a turnkey Scrum team. However, they didn’t have a large budget. We put together a five-member team, comprised of a part-time product owner, ScrumMaster, and software architect; and two full-time senior full-stack developers.
The team produced more than the client anticipated and they were blown away by how much got done in the six-week trial run. They were so happy with the results they immediately signed up to keep the development team working and wanted to expand the team to tackle more than originally planned.
We were not able to leverage our ideal mix of Scrum team members, but we were still able to produce high-impact results. How did we do this? First, we followed the guidelines I just outlined, favoring a smaller team comprised of senior generalists, to put us in a position to succeed. Second, and most importantly, we stuck to the core disciplines of Scrum. That discipline made this a shining example of how quickly a solid Scrum process can produce results.
What are some constraints that keep you from building the ideal agile development team? Leave us a note in the comments section.
