Let me guess… In the company where you are working, you simultaneously take part in 10 different projects. The organization’s management team is hearing the word Agility everywhere on the market, finds it cool, and wishes to catch the wave. Unfortunately for you, their understanding of Agility is that you still have to work on all your projects at the same time.
Do you feel overwhelmed? Are you and your team feeling frustrated and helpless regarding the situation? You know, there’s a solution. First, you must ask yourself what should happen in order for you and your team to be able to focus on one project at a time.
My team and I have worked with several agencies and small businesses over the last few years. Before their transition to Agility, many of them were spreading their efforts over several simultaneous projects and were being guided by the client who was shouting the loudest.
Why do you have to work on several projects at the same time? The answer I usually get is that the team has to meet the clients’ needs as soon as possible. However, by experience, I know that the real challenge often lies in the fear to have to manage the clients’ expectations.
This graph shows the efficiency problem when someone works on several projects simultaneously. Each time the person goes from a project to the other, they have to switch to the project’s specific context and resume work where it was left the last time. Therefore, what usually takes 10-15 minutes to get ready for the day is increased each time we switch from one project to the other.
There are no magical solutions regarding the number of projects a development team can carry out simultaneously. In fact, it depends on the projects’ size and the team’s capacity. In a certain context, a team comprising 5-6 members may be able to work on two simultaneous projects. However, in another context, the same team could spend all their time on one big project for an entire sprint.
The ability to share and distribute work among team members is a factor that could guide you through decision making. Basically, you will not get more benefits if the entire team is working on one project, but everyone is stepping on each other’s feet.
Suppose we wish to mobilize the entire team on one project for an entire sprint. A sprint (or iteration) is a fixed period of 2-4 weeks during which the entire team works together in order to deliver a potentially shippable product increment.
If you accept this eventuality, you must ask yourself the following questions:
When you have this kind of dilemma, what becomes crucial in the equation is to manage your clients’ expectations.
The main complaint I’ve heard when a team focuses on only 1-2 projects during a sprint is the clients’ response time for content, tests, or comments. If you are facing this problem, I suggest that you review the way you communicate and collaborate with your clients.
With Agility, continuous planning is very important. Actually, it is crucial for you to negotiate in advance with your clients the availability of the members of their staff that you’ll need during an iteration. If you don’t do it, your request will look like a last-minute one. Thus, you reduce your chances of having them meet your needs or process your requests.
Now, let’s talk about the collaboration and communication with your clients. It’s paramount to understand that one of the goals of Agility is to bring clients closer to the development process in order to ensure the delivery of maximum value as soon as possible.
In this context, as a business, it is important to question yourself on the way you wish to reinvent your experience with your clients in order to involve them as quickly as possible in your Agile process. It is also important to know that not all clients will be open to work in such a close collaboration. Therefore, it is important to adjust to your current clients in order not to lose them. However, how can you establish a different relationship with new clients?
Sometimes what I hear is something like: “Come on, I can’t tell my client that I will not work on their things for two weeks!” My reply is that it depends what we mean by “working on their things”. Instead of developing code during a sprint, someone in the organization could collaborate with the client to identify their needs, which will actually ease the team’s work.
Regarding client relationships, the item on which it is important to question ourselves is the way we are treating our clients. Are you treating them like partners? If you do not feel comfortable telling your client that you will not be working on their project, it may be a symptom that the relationship needs to be established on new grounds…
Therefore, if your teams each have 10 simultaneous projects, what should you do now? Should one team focus on one or two projects per iteration? As I mentioned earlier, it always depends on team capacity. For instance, suppose one team has one designer as well as many developers and integrators. What would happen if you would suggest that the entire team works on a single project? Would some team members be reluctant? Would they refuse saying that it is impossible? Here is a good question to ask them in such cases: “What happened the last time that we tried to work this way?”
This question can cause an interesting reaction, since they probably never tried it. Thus, they let fear take over. Sometimes, it may be useful for a team to try this new way of doing for a few iterations in order to learn and subsequently adjust. In the context of 2-week sprints, the cost for trying it is not very high. At the very worst, the team tries it during two weeks, and then stops the experiment. However, if you and the team are satisfied with the results, it provides the organization with a lot of possibilities.
What other strategy would allow to reduce the number of projects in a team’s portfolio if they would focus on one project at a time? The solution that is most obvious would be to create other multidisciplinary teams that are able to carry out development projects. When creating new teams, it is important to ensure that their members will have a combination of skills allowing them to execute as many different types of projects as possible.
Before allocating new projects to your teams, you must first reduce the number of projects in your portfolio. At least, try to slow the pace at which new projects are added to your portfolio in order to allow your teams to catch up. Once the number of existing projects is reduced, it will be easier to establish a steady pace in your teams… and you will get closer to your clients when carrying out their new projects.