How to manage agile projects with high staff turnover

Question

Background: a large consultant company wants to better utilize their consultants time when they're between assignments. The plan is to have an internal concept managing internal projects, which aim to deliver value to the company (sale demos, internal products, etc.) and also give the consultants the opportunity to gain new skills (for example get experience working as a Scrum Master).

Using Scrum for these projects are getting mixed results, since staff leave the projects pretty much immediatly when they get a paying assignment which makes it impossible to get a somewhat consistent velocity.

These circumstances also increase the demand on the ease of which one can enter these projects, for example readability of code, documentation of decision making etc. One risk is that this could increase the waterfall-nature of these projects, which I very much would like to avoid

So how to manage these projects? Project methods to use? Pitfalls to avoid, and how? Any help would be greatly appreciated

Answer 1

Scrum assumes a fixed team so like another responder said, it isn't a surprise you have found Scrum frustrating. And while saying you want to "utilize" people more pushes against the false assumptions you can 100% schedule people, however, I agree with the goals to help folks not at a client to find ways to focus on other valuable pursuits.

This sounds more like the concepts like "FedEx Days" or "80% time". Essentially, coming up with guidelines for folks but not trying to create projects with dates, deliveries or commitments. Pick up Daniel Pinks "Drive". It may also give you some ideas about how you can help motivate and guide consultants on the bench.

I've worked in consultancies and in my experience, we were always excited to work together when back at our home base. It did give us a way to make our business better and learn from each other and the challenge of leadership was to find ways to facilitate that for us while also supporting clients.

As far as more specific tools, you might try a Kanban board, but I would seriously ask why you need to measure speed (velocity or thru put). Maybe you just need a visible indicator or way to hand off or a way to see the next thing to pick up when you get back. Build the tool to suite you, don't drive it with process. Good luck

Answer 2

I am not sure that Scrum is the right tool for the job in this case. A similar case can be found in developing free/open source software, where contributions are intermittent and heterogeneous.

Probably a system without specific iterations, but with continuous deployment and variable velocity, like Kanban, could suit you better.

Answer 3

There isn't a silver bullet to fix your organization's problem that they will not invest in internal projects. The way to successfully do a project is to staff it realistically and execute with that staff. If you have folks that are simply killing time they will not be interested nor committed to their short-term-unknown duration assignment.

I would suggest that using an iterative project methodology is actually hurting you.
Why? Agile methodologies rely on a constant team with constant achievable velocity. If you have a team of 5 and in a 3-week cycle (sprint, even) you lose 2 folks, you lose control of that velocity and will either have to under-deliver or change your development cycle timeframe.

I believe your projects could be more successful if you devoted a smaller team (2 people?) to author your requirements and make some UI mockups (for example) in very small work packages, then when you get a developer on the bench, you assign him or her a small amount of work that your organization can commit to letting them finish. In our agile and non-agile projects (and some with hybrids of each) we make our definable and testable work packages as 'doable' as possible in under a week. Anything greater than 3-5 days of work is questioned in hopes of being broken apart.

Answer 4

i think best way for you is to create a backlog first , try and do vision of what exactly is that you want to achieve from this tool . Once you have backlog as mentioned above try to have 2 ppl on board for long term . These guys should understand design/requirements . Then you can keep on adding ppl around them . For an internal project no company in world will resources or money . So do demo's from time to time to update stakeholders and make use of people on pool

Answer 5

Scrum suggests to have a fixed team so it will be hard to track velocity for your project.

what I would suggest is to divide tasks to smallest size which can be completed within a day and then apply Kanban style development cycle. it will help to get work moving as well as you can monitor individual's contribution.