4
How to choose the right team?
The chart below shows the correlation among technology, requirements, and people building a software product. Based on their nature, software projects are complex, rarely complicated. But if a good team is found,
'complex' might become 'complicated', because most of the times technology is not certain, requirements are not certain, and people are changing. And a good team means a permanent one. They've had the time to develop communication patterns. They can provide reasonable increment every single time, in every single Sprint. This can lower the 'chaos factor' and a complex software project suddenly becomes just complicated. A great team can build the software from the bottom up9 .
Stacey Graph, source
http://pm.stackexchange.com/questions/389/when-to-use-waterfall-when-to-use-scrum
Here are some key factors worth considering when looking for the right Scrum Team:
● Knowing and accepting the complicated nature of technology and possible changes in the requirements regarding the product, the team is capable of addressing challenges along the way properly. Can they prove it by showing a number of completed, successful projects? How would they approach a problem if the business needed to change; when would they introduce the change? What is their standard Definition of Done?
● How responsive is the team and to what level does it welcome the changes to the vision, direction, and the code itself? Do they treat email/chat/video communication as a part of the job, or as a distractor from programming? Do they welcome changes during a Sprint and if so, would they later blame you for not delivering the software? Who do they think is able to change requirements besides Product Owner?
● Is the team focused enough on a specific technology? What is their technology stack of choice? How long have they used it? What is their quality process? Can they name the biggest downsides of the development stack? How do they assess if the given technology is able to solve a business problem efficiently? What is their most remembered problem when it comes to the technology, and how did they deal with it?
● Are the members tight together and have they got cohesive skills, or are they a bunch of individuals? Do they understand consequences of the changes in the code provided by themselves and the team10? How long have they worked with each other? How many projects have they left behind finished? In Agile, understanding each other is the key. Can the outsourcing company tell you whether the team assigned to the project will be a project team (the one that is built for the project) or a permanent team? If it is a permanent team, at which stage of teams development is the particular team now?
Stages of a team development, source: https://programmentor.wordpress.com/tag/team-development/
● Tuckman's stages development model11 shows the characteristics of an effective team. In the 'forming' stage, team members get to know each other. In the 'performing' stage, everything is right in the place. If your team is to be formed for the project, you have to be aware that these stages will affect your project and the velocity of development of your Development Team. A properly formed team becomes a High Performing Team and can be 100% more productive than a Working Group (Forming Team).
'A collocated self-organising team is 100% more productive than otherwise' - Boston Consulting Group.
● What percentage of developers have an engineer degree? How many of them can speak English and/or any other popular language? Statistically, developers with higher education and languages are more mature and disciplined, they can bring the software to the end. On the other hand, what are the team members software development years of experience? A reasonable median might be 3 to 6 years.
● Do developers run in the same cultural circles as the Partner? Laughing at the same jokes, understanding the same context and background brings people closer. More importantly, the same context helps developers understand the Partners' business12 .
● Price. Lower prices don't mean bad quality, it's just the geographic, cultural, and economic reality. However, unexpectedly good prices often mean a 'too-good-to-be-true' situation and contract. And as a result - the lower quality of the product itself.