Providing talented and motivated people is more important than simply delivering project capacity. I truly believe that the best results come from the best teams and not simply from a group of individuals that happen to be working together.
There are many things to consider when preparing to deliver an IT project. We need a common goal, an agreed approach and some idea of how much effort it’s likely to take. Then there are delivery constraints, quality levels and usually a set of releases to plan and coordinate. When delays do occur, they are often at the beginning. Careful planning from the outset can help to reduce this risk and ensure that we start as we mean to continue.
In the midst of all this activity, it’s easy to overlook the nature of the team that will be doing the work. Of course, we need to consider its size and the skills and experience of its members. These are prerequisites that must exist if we are to succeed. But a team can be so much more than the sum of its parts. I’ve seen what can happen when people really gel, the special hive of activity and understanding that comes from working with people you know, respect and are naturally comfortable with.
This does not occur randomly. It takes time to build effective working relationships. For me, this starts with a company culture that helps to align everyone with a set of shared values. I am still surprised and very pleased that a high percentage of our own new starters come from the personal recommendations of existing staff. In this way, we start with a workforce that has mutual respect, interests and shared experiences. We do make mistakes sometimes but most importantly we learn, adapt and improve from them.
Building the right teams is only half of the challenge. Once we have something that works well, it’s in everyone's best interest to try and preserve it. Changing even one person can have a substantial impact on team productivity. This is before we consider replacing the domain knowledge that is lost when someone leaves.
The concept of a dedicated team is simple to describe and difficult to master. We build a team that complements your way of working and then keep it together. You will get to know the people you are working with and build a solid working relationship with them. We won’t treat your team as a set of resources that can be swapped around whenever it suits us. Each chosen person will be dedicated to providing you with a quality service. I only ask that you help us to keep everyone motivated and informed. After all, the happiest people deliver the best work.
I do appreciate that people leave from time to time to pursue other challenges. At Objectivity, we have an attrition rate that’s substantially below the industry average. Still, there are rare occasions when we need to introduce someone new. When this happens, we will work with you to conduct an effective handover that does not disrupt your business or your objectives.
I’d like to share my views on why dedicated teams can be so effective. Our model has 7 key attributes. If you would like to discuss this further then please get in touch, I’d be really interested to hear your thoughts.
7 Attributes of a dedicated team
1. Location independence
A dedicated team should be location independent. In other words, it should be possible to work onsite, or remotely, from a different location.
This is an important objective for a nearshore software supplier. We prefer to begin by working onsite with you, where we can meet your people and start to understand your business.
After a while, the team will transfer back to our development centre in southwest Poland. We create, with you, a set of success criteria that will help us to decide the right time for this transfer. As we continue to work together, there will be times when one or more members of the team will visit you. Equally, you are welcome to come and spend some time in our workplace. The key here is to find a balance that supports a strong relationship between client and Supplier.
We are, of course, mindful of the additional costs that come with working on site. With a little forward Planning, these charges can be easily controlled. It’s certainly not a good reason for never spending any time together.
2. Single and multiple teams
Our model caters equally for the provision of single or multiple development teams. Usually, each team has a number of core team members working alongside a group of shared resources.
Core team members work only within a single team and are fully utilised by that team. Shared resources may work across multiple teams, helping out as the need arises.
Typical examples of core team members are programmers and testers. Typical examples of shared resources are technical architects and UX engineers. There is no magic formula for the distribution of people. A project manager may play the role of a core team member or a shared resource. Whilst each team should be largely self-sufficient, there are occasions where specific problems require specialists to help out a little.
For larger engagements, there is likely to be a programme manager or onsite coordinator to help plan activities across multiple work streams.
3. Team composition
Team members may come from different sources. For example, we may supply programmers and testers while you supply project managers. Any combination of resources is possible and this will depend on the nature of the engagement.
It is not uncommon for responsibilities to change over time. You may provide a business analyst when we first engage, as a subject matter expert. Once our team members acquire sufficient domain knowledge, it may be possible for us to act as domain experts on your behalf.
Regardless of team composition, we need to keep everyone happy and engaged. The team should be empowered to decide amongst themselves how best to fulfil their responsibilities. We find that this promotes a healthy and productive working environment.
4. Information and communication
Stakeholders should have accurate, accessible and appropriate information available to them at all times. It’s really hard to improve what we can’t measure. High visibility of progress will ensure that people are able to react and respond quickly to any issues that arise.
Physical reports may be helpful but they should not be a replacement for person-to-person communication. If you learn about an important issue from a report then we are not communicating well enough.
When working with dispersed teams, we use online systems for sharing information. In this way, interested parties can pull information from the system rather than waiting for someone to produce it.
5. Quality and efficiency
In our team model, quality and efficiency are grouped together. They form an essential, and healthily competitive, partnership. Efficiency is about doing the right thing and quality is about doing the thing right. There is no great benefit to storming ahead at a 100 miles per hour if the results are sub-standard. Similarly, high quality results won’t add sufficient value if it takes forever to produce them. A dedicated team seeks to manage these elements to produce a balanced outcome that matches or exceeds your expectations.
Both the quality of a service and the quality of the deliverables it produces are criti-cal factors for success. Quality is the responsibility of the team and should not rest with any specific person. Whilst this is true, the values and principles of the team members will greatly influence the quality of work. For a dedicated team, this is ‘built in’. Testing starts at the very beginning and continues until development is complete. There is an effective process for finding issues and also for avoiding them. Prevention is certainly better than cure when it comes to defect management.
Working in 2 or 3-week iterations means that you see frequent progress and are able to influence what happens on a regular basis. Being able to automatically build and release software helps to reduce effort for repetitive (and important) tasks.
6. Agility, flexibility and continuity
It should be possible to add additional teams whilst effectively managing operational risks. It’s important to ensure that:
- There is no unnecessary disruption to existing teams.
- Live systems continue to operate at agreed levels.
- There is no reduction in the quality of the service as a whole or the deliverables that come from it.
We apply a ‘seed and grow’ approach to building new teams. Each new team centres around one or more established people from an existing team. This limits disruption to teams that are already in place. It also ensures that new teams have the support and expertise they need to succeed.
There may also be periods of time where there is a little less work to do. Careful management of work priorities and the ability to apply some resource flexibility helps to address this. With short iterations and weekly assurance reports, everyone will be well prepared to inspect progress and adapt accordingly.
7. Continual improvement
The dedicated team model works well for our clients and for us. Starting with the process here, we tailor the approach to suit your specific challenges and preferences.
It’s definitely not a case of ‘one size fits all’ when it comes to building an effective working relationship. This information provides a suggested starting point rather than a recipe that cannot be altered. It’s encouraging to see how this model has evolved since we first put it into place. As good as we feel it is, there is always room for improvement. With your help, we can continue to refine and enhance what we already have. We all make mistakes from time to time.
At Objectivity, that’s allowed, as long as we learn from them and improve from the experience. I can’t promise you a fault free journey but I can promise that we’ll do our absolute best to help you succeed.