1
  1. 5 products on 4 platforms
  2. ~100 projects implementations at different stages(Where a project is a set of products customized for customer.)
  3. 15 developers + 5 QA's
  4. Swarm of small clear tasks/CR's/Storys from 8 to 100 hours size, easy to estimate as they are simple and more or less similar.
  5. Inflow of new story's for project and product is unpredictable

What is best practice for such a situation. I am intentionally omitting my solution to search for an alternative solution.

  • 1
    In comments, you're saying you don't have a problem and that your system (whatever it is) works fine. If it's fine and there's no problem, then this is not an on-topic question for PMSE. If there is a problem, you should at least consider the possibility that experienced agile practitioners might be giving you good advice about how to solve the framework implementation problem as you've posted it. PMSE follows a Q&A format; it's not a discussion forum, or a place for generating abstract ideas for non-problems that you aren't having—or for guessing what your problem might actually be. – Todd A. Jacobs Nov 8 '16 at 2:27
7

TL;DR

How to share developers between multiple agile projects?

You don't. Doing so is inherently non-agile.

This smacks of an X/Y problem, where X (the real problem) is likely to be an executive mandate to "do more with less" without prioritizing projects based on both business value and resource constraints. However, you or your organization may have decided to solve for Y by looking for a silver bullet that will make the impossible possible.

There is no silver bullet. Make sure you're solving for X, rather than Y!

Your General Options

In an agile practice, you can generally choose between:

  1. Fixed, cross-functional teams that work on different projects, but only one at a time.
  2. Product-based teams, where the teams are formed around each product. Note that each product will have its own separate Product Backlog, and each team will work from exactly one Product Backlog.
  3. Feature-based teams, where teams are formed around features (rather than projects), who may either share a single Product Backlog or have one backlog per feature team.

How you delineate projects, products, and features can complicate this, but the distinction between a single product with many features and multiple products should be your guiding principle. A great deal depends on correctly conceptualizing the project, and not being afraid to split off related projects when they no longer fit within the bounds of a single product or team.

You Must Address Resource Constraints.

In all cases, you can't really do what you seem to be trying to do, which is spread the peanut butter ever thinner without adjusting your resource constraints. Specifically:

  1. 20 team members are not enough to support 100 concurrent projects. One team, one project! is a hard rule with all agile frameworks.
  2. Unless you've done a better job abstracting your architecture or building cross-functional teams than you've described here, you don't have five products, you have twenty! As a general rule, 5 products * 4 platforms = 20 product backlogs.
    • This would require at least 20 teams unless you prioritize and sequence the deliverables.
    • You might also consider cross-functional teams that can build one product from one backlog that targets multiple platforms (think PhoneGap as an example), but you still don't have enough people to staff for five such teams.

There are other problems with your conceptual approach, too, but they all boil down to the fact that you're trying to do too much with too little. No matter how you structure your projects, you can't do them all at the same time with the resources you have. You either need to add resources, prioritize the use of your available resources, or (ideally) do both.

  • Actually, such team works for years in the configuration I mentioned and quite successfully. One developer one project simply doesn't work, as there is nothing to do for one developer on one project, and the amount of new stories can unpredictably change in a week. Currently, it is one backlog for each customer, for all product on all platforms. – Alexander Averchenko Nov 7 '16 at 18:46
3

CodeGnome gives a great response and he's 100% correct, you don't.

The number 1 tool I've used to explain why, to management, is a ten minute exercise that takes nothing but a blank piece of paper and a pen. I call it the "Multi-Tasking Letters Game", I'm sure it has other names.

To play:

  1. Have each person lay a blank piece of paper in front of them landscape (on its side so wider than taller).
  2. Draw three equal columns.
  3. Draw a horizontal line about two inches from the top.

You now have six boxes, three small ones on the top and three long ones on the bottom. 4. Label the small boxes "1", "A", & "I" (Roman Numeral 1) 5. Explain the exercise

"Your job is to create characters. Each column represents a different product, the numbers, the letters and the roman numerals. Each product consists of the first ten characters in the sequence, A-J, 1-10 and roman numerals 1-X"

  1. Explain the first round:

"In the first round we want to make sure we are working on everything so it all gets done as fast as possible. So you will work from left to right, writing down "A", then "1" then Roman numeral 1 before going on to do "B", "2" and Roman Numeral 2. When you have finished the entire page please raise your hand.

  1. With a stop watch ready, tell them to begin. Start timing. When the first person raises their hand, hit the Lap timer. When the majority of the room is raising their hands, stop the timer.

    Generally the first person will finish somewhere around 25-30 seconds with everyone finishing before 40 seconds have elapsed.

  2. Record the results in a highly visible location.

  3. Explain the rules for round two

    "This time we want to focus on a single product at a time. So start by doing A through J, then move on to the numbers and then the numerals.

  4. Position yourself where you can see multiple participants pages easily. With the stop watch ready tell them to begin.

  5. Scan the participants and as soon as you see someone move to the number column hit the Lap timer. When the majority of the room is done, stop the timer.

    Generally the first person will finish the first column 4-6 seconds and the entire room will be done in less than 30 seconds. The total time for round 2 will almost always be less than the time it took the fastest person in round 1 to complete.

  6. Record the results and reflect on what happens when you focus on only one thing at a time.

  • Interesting game, but nothing to do with a situation when demand for product and project is unpredictable. – Alexander Averchenko Nov 7 '16 at 21:57
  • 3
    Alexander- Your first issue has nothing to do with the work or projects. Whether you're multi-tasking on projects, user stories or tasks, it will cause a problem. Looking at your response to CodeGnome, sounds like you might benefit from a Kanban workflow over Scrum. In either case, you still need to get people learning to focus on one "item" at a time, be it project, story or task. – Joel Bancroft-Connors Nov 7 '16 at 22:14
  • There is no priority problem, as one prio system is maintained through the whole portfolio. Developers always work on one issue at a time based on top prio wich are negotiated based on customer expectations and value. Yes, there is a kanban board, problem is that it either too big to be observed, or to filtered to see the helicopter view of a delivery pipeline. Another issue here as prios are changing, thus lead time is not reliable metrics. We can also operate with quite precise weekly/monthly velocity, as there is CD with prod build after QA phase. And most of the issues are independent. – Alexander Averchenko Nov 7 '16 at 22:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.