Multiple Projects, Multiple Clients, Same Dev Team... Advice appreciated
I am hoping some of you may be able to offer some advice or point me in the right direction.
I recently completed the CSM course, and have now taken the role as scrum master within our digital agency. We have a dev team that consists of 3 developers, 2 designers and 2 UAT testers.
We work on multiple projects at a time for multiple clients. We started working in agile/scrum around a year ago and have gradually tried to become more and more 'scrumified'.
I am running into a number of difficulties at present, we are currently working on a number of projects and this means that the dev team have to attend a number of stand ups every day, in addition to the other meetings such as sprint planning and retrospectives, and this is consuming a lot of their time.
I am also finding it difficult keeping up/track with where we are at with all the projects (updating documentation/velocity/burndown charts etc).
Does anybody have any words of wisdom on how best to tackle the issue of adopting a scrum approach for multiple projects simultaneously, using the same development team?
If anybody could point me in the direction of any articles/books or real life advice it would be really appreciated.
> ...how best to tackle the issue of adopting a scrum approach
> for multiple projects simultaneously, using the same development team?
Scrum has a product rather than a project focus. A team must be able to commit to Sprint Goals for the delivery of successive product increments. Team members can only work on multiple products simultaneously if their ability to make these commitments will not be compromised.
Sometimes it is possible to combine the work for multiple products into a single product backlog. This requires the existence of an aggregate product which can be represented by a single Product Owner. The problem of managing any competing interests can then be reduced to a matter of prioritization.
If the products are indeed separate, then you might consider interleaving sprints so that each product is worked on in rotation. The sprints would have to be short enough to ensure that each product is worked on at least once per month and a potentially shippable increment is delivered.
Its a priority call really. Create a single backlog. Each product can be broken into features - release MMF per product per sprint according to priority order.
I fully agree with Ian. One further point:
One purpose of Scrum is to protect the Development Team from e.g. too many meetings. If you practice a "Multi-Project-Scrum" where every "Project" gets its own meetings within the same Sprint, one can easily understand that you're running out of development time...
Are there more Scrum Teams on your company? If yes, perhaps you can redistribute the tasks so you can go with Ian's advice and create a single Product Backlog for each Scrum Team.
Thank you for the input.
I should have added in my original post, we only have one scrum team.
I am looking into the idea of a single backlog, and we already do this (to an extent) on our kanban board at a very high level.
As an agile coach for my company, I had to get several teams like yours into agile as well. The main thing is to get everything under roof. That is the key. If you want the team to work productively and then you need to make it visible to management the business value for each item your dev team is working on.
These are two approaches that finally worked, one is using a fast paced scrum process and the other is a Kanban process. I will explain the scrum process.
1. Create a single backlog with all projects items (you can use a shared Excel here). This backlog contains all the items that your team is aware that they will have to work on in the next couple of weeks or months.
2. Get the business to prioritize these items in an order or importance to the company. When I mean business here, it has to be the personal who can decide what is more important at a given time. Any new item coming in goes to this backlog and needs to get prioritized.
3. Plan for a weekly sprint. Have the prioritized list and plan with the team the items the team would plan for the -coming week (we did this every Thursday).
4. Get the team to give efforts / estimate etc.. and identify how much your team can do for the week. (don't worry about story points yet, just go with hours as much as possible and not days)
5. Commit this to business and make sure that you and the team delivers on it's commitments. Initially the item list will be less, but as the team realizes their capacity, it will increase
6. While the sprint is going if you get any new items coming, plan them for the next sprint. If these are severity level 1 items, then you will need to discuss with business and show the disruption to the whole sprint by this item.
Most of the time when the actual cost is shown, business tends to push back the item. For instance, if we stop and start an item due to anything, then the cost for that would actually double then what it was originally estimated.
7. Keep monitoring and improving on how the team is meeting it's commitments (do a retrospective at the end of every sprint). I am sure there will be challenges as you are changing the mindset of people, but keep monitoring the scrum process and improving.
8. You can slowly then get to a sustainable pace and slowly move to two weeks sprints and bring sanity to the situation. But it will take time.
It sounds like team is part of other teams to get projects done. Sounds like stuffing projects by skills not needs.
There are many ways how to show it - e.q. you can count hours spend on different projects during work - it should be obvious to see negative results of such actions. You can find many resources in internet about multitasking and scientific effects of it. I heard once about company having several dozens of projects running theoretically and only few in reality. Showing work-in-progress + plans could also bring attention.
Sometimes starting project sound more important than having it done - it may come from times where scheduling money on starting initiative meant being sure something (maybe very late) will be delivered. Sounds stupid but shows reality when you need to budget in long horizon. Of course it's huge organisational dysfunction.