In the IT world, teams are usually organised around products. We know well scrum and related roles like Product Owner, Development Team or Scrum Master. What if a team is additionally involved into a project? How does that affect its members? Who is the decision maker then: the Product Owner or the Project Manager? How to plan things to achieve both: product goals and be in time with project tasks?
If you’re interested in the answers to these and other questions, here’s the story of one of my squads.
About the Squad
The Squad consists of 5 members developing two products in Java in enterprise content domain. In short, we are responsible for one service that synchronises objects between one system and another (large document archive), as well as the API layer that sits on top of this archive.
More than a year ago we started a new journey – a project – migrating the document archive to another target platform. We are talking about a number close to 1 billion documents that need to be transferred from one system of record to another. We are still in the early stages of the project, but looking back I can already share a few thoughts, especially about the impact that such a project has on the daily work of the squad and the challenges we have already had to face.
Why do I need a second team?
The nature of projects is that they usually consist of people from different teams or areas. It is no different in our case. Our project team consists of Business Analysts and Ops engineers from other areas. Next to that there is a Solution Architect and Project Manager. Those are people from different units, playing different roles and physically located in different places, with whom we must work as a team. What I mean?
We need to understand each other (technical vs business language), understand each other's roles, not be afraid to challenge ourselves and, finally, there should be a trust between us.
Project team as any other new team must go through phases like forming, storming, norming and finally performing. There's barely anything we can do about it, except for a few things that might speed up the process a bit. Here's what we did to act more as a cohesive team:
We started talking openly about the communication gaps. In retrospective sessions (yes, a project team should have the improvement sessions!) we clearly indicated that communication in our team is not at the level we would like it to be. It is difficult to improve it right away, but at least team members are more aware that one person may not fully understand what the other person is saying.
We introduced the internal review sessions, where each team member elaborates their own project things. It doesn't matter if it's not finished yet, if it's boring to others or if it's not very important. The discussion matters.
Ice Breaking Sessions - To get to know each other better, we also organised ice breaking sessions. Thanks to this, we were able to get to know the private side of our lives a little better.
Why are my events doubled?
The biggest nightmare of everyone involved in the project: meetings.
In addition to the standard product-related scrum ceremonies, the squad participates in fairly similar (though naming and conducting may differ slightly) project-related meetings. Those might include status meetings, planning sessions, refinement sessions, already mentioned improvement and review sessions to name just a few of the cyclical ones. Basically, the team ends up with duplicate product and project events. You can probably imagine how much confusion and irritation this causes. What we did to mitigate that?
At the beginning, we've brought together (aggregated into 1-2 days) product and project events. This is to overlap the cycles. Both product and project events are held in 2-week cycles. This way the team can continue to work in 2-week cycles, which provides some stability and repetition in our professional life.
We've shortened the product related events. These are still important. As part of these activities, we manage our regular quarterly business and technology demands. However, we have shortened the daily events, as well as the refinement and planning sessions. On addition to that, we have extended our squad retro period to one month.
Most importantly, we stopped discussing project matters outside of project meetings. We had a habit of initially discussing things (in Polish) during our internal sessions and then kind of doubling the discussions within project ones. We got rid of that.
Why Project Manager tells me what to do?
Squad members involved in a project may be confused when it comes to managing the work. On the product side, there is usually a Product Owner, and on the other side, suddenly a new person appears ordering work and setting priorities - the Project Manager. How we approached this matter?
We started by clearly explaining to the team the role of the Project Manager. It should be transparent that this person will require and regularly check that promised project tasks have been delivered.
Secondly, the key to success is close cooperation between PO and the PM. There should be pre-agreements, usually agreed with senior management, about the amount of work given squad can devote to the project. In our case it is a bit flexible and changes depending on the quarter. The PM regularly checks with PO on the squad capacity for the coming months and based on that can plan work packages accordingly.
Why do I need to plan twice?
How to realistically plan the work to achieve both product goals as well to complete the project tasks?
The priority is very often in both places. It happens that there is something urgent to finish within product and project assignments. How we deal with that?
Above all, we have made it clear that business continuity duties always have the highest priority. If something is not working on production within our product services, it is obvious that we spend time on it. Sometimes project tasks suffer because of this. The key is to communicate that as early as possible within the project. That way also project work can be shifted accordingly.
We also have a concrete approach to planning. As mentioned earlier, the product and project planning are scheduled next to each other. Our approach is to first do product planning, keeping in mind the need to leave an agreed space for project work. Then we usually visualize it - we use simple sticky notes to illustrate the amount of work that falls on specific working days. This gives us a clear picture of the dependencies and still available time space for the project tasks. With such artifact in hand, we usually move on to the project planning. Of course, we usually add some buffers as well.
Continuous Experimenting
As you can see, product and project involvement bring its own challenges. There are definitely many ways to deal with such case. Our approach is to keep the whole squad engaged into both. If you find yourself in such situation, especially if you have a bigger squad, you may want to consider splitting the team and dedicating one part exclusively to the project and the other to the product. This could even be slightly more efficient (not all team members will need to be present at all meetings), but it could also pose some additional challenges (e.g. squad integrity).
Eventually, the key to survival is to accept that the way you choose to work will certainly not be perfect. It cannot be assumed that processes established once will work all the time. Next to the well-known practices like Continues Integration and Continues Delivery you should add the Continuous Experimenting.
