I work with an agile team of 6 engineers. The agile project they are starting consists of two products, so the team will have two PdOs, two product roadmaps and two seperate backlogs. Actually they will form two subteams of 3 persons each. Is there something that I (as project manager) should pay attention to, try to secure or try to avoid in order to be successful in this "extreme" case?
Any similar experiences out there?
Many thanks and good day to all!
Dimitra Saving Changes...
Sort By:
Juan Escobar LopezSenior Project Professional| ENELBogota, Cundinamarca, Colombia
Good Day Dimitra
As a project manager, my advice is always keep your focus on the baseline and the project charter; Try to close the scope, avoid open topics (indefinite structure inside of your WBS), and keep an eye on the cost control (EV, PV, BAC); by the other hand try to get regular meeting with the stakeholders.
Is my opinion, and that´s my way for handled projects.
Thank you Juan!
Our scope is a bit flexible at this early stage (we have the high level product structure but not all the details yet). We hope that it will be much more clearly defined on the way.
I'll keep your advice about stakeholders. Having them close to the team will make a difference!
Have a nice week! Saving Changes...
Rajmahendra HegdeAgile Transformation Coach | Freelance ConsultantChennai, India
Hi,
My view in this is, if you have 2 PB then its good to have two teams. If you can make two independent team then its good. If you have option of shared resource both team better to avoid in beginning. If team is read to share time in both then its ok. (depends on how team like to handle.)
Other than that rest goes as per Scrum etc.. Saving Changes...
Sure! Two (sub)teams seem a must! Otherwise multitasking may decrease our focus!
But then, the teams are too small (3 persons each). I hope it will not be dysfunctional...
Thanks for the opinion! Saving Changes...
Hannes KropfProject Manager| ITERGO GmbHHamburg, Hamburg, Germany
Hello Dimitra,
two teams might be a good solution if the teams are truely crossfunctional.
If not and you need one skill in both products thats is only owned by one person then ... it is not such a good solution.
Since you have written that one scope is a bit flexible. According to this I would look for a solution to work on one product for maybe 2-3 months, make a real shipable product and then change to the other product and do the same for 2-3 months.
Another solution is to search with both product owners to find a basis of both products, work for a time on those stories as a whole team and may be split after the base is worked out the team into two teams.
In either case 3 is a possible minimum that you can work with, but you need a complete team. All three members have to have the skills you need for either product.
I am actually working with a team of three and they are working very well, the product is good and the sponsor is enthusiastic. The plain number of three is no hurdle for success.
Good luck and maybe you can share your experience here.
Best regards,
Hannes Saving Changes...
Francisco AbreuPortfolio Manager| Banco Central do BasilBrasilia, Df, Brazil
Dear Dimitra,
I’d like to contribute with my past experience.
I’m assuming some premises:
1. You are developing a IT Project.
2. It is compound for two products which they are integrated and complement each other. In other case, you would be management two projects instead one project with two (sub)teams.
Some time ago I had working in a project with these same characteristics and my learned lessons were:
1. Maintain two (sub)teams working in parallel is the best solution. Each team need to focus your own objectives.
2. Construct only one integrated Database for two projects.
3. Assign one person (of any of the teams) as responsible for creation / maintenance of that data base.
4. In the moment of definition of histories of each sprint of one (sub)team, it have the presence of one engineer of other team. This procedure has the objective to identify common parts of two products, increasing the expected integration of them.
5. As a PM, you worry about balancing the amount of story points for two teams. This avoid conflict with you.
I believe that integration is the main point to be pursued.
I'm going to use a metaphor:
"You need to build a tunnel through a mountain with each (sub)team on both sides. If you integrate them you will build a tunnel. If not, you will build two of them ".
Thank you Fancisco and Hannes for your thoughts and suggestions!
For the moment, we go on with the 2 teams, 2 seperate products/product backlogs (integrated seperately) and 2 Product owners.
We will have info sharing meeting once a sprint so that each team knows what the other is doing.
We plan to go like this up to the end of the year. Up to then, we'll continuously evaluate the setup and see if we need improvements.
I'll come back to share the outcome and the experiences!
Have a good day,
Dimitra
Saving Changes...
