search

swcarpentry / managing-research-software-projects

Managing small to medium-sized research software projects.
https://swcarpentry.github.io/managing-research-software-projects/
Other
37 stars 13 forks source link

Advocate Scrum-style "product owner" role for PI with biweekly meetings (rather than embedded) #5

Closed duncanwp closed 7 years ago

duncanwp commented 8 years ago

One key omission for me at the moment is the elicitation and management of the requirements (or product backlog items). Where these come from, who takes ownership them, and how they are prioritised and chunked up will have a huge bearing on the success of the project.

There is too much to cover in less than a day, but I think getting some fundamentals in there is important. These will vary depending on the management approach but if you're going down the agile route then I could provide some useful links/resources.

duncanwp commented 8 years ago

Sorry, I've just realised that you do discuss requirements at length in the 'sturdy' development document. I would be extremely cautious about applying such a methodology to small/medium projects though as you will almost never have enough up-front resource to do a proper requirements and design phase.

gvwilson commented 8 years ago

Agreed - what do you actually do in practice? "Go and talk to the PI" seems to be a common approach, but is also a common way to get into trouble.

duncanwp commented 8 years ago

In my experience the Scrum model works quite well for this, but it depends on the level of involvement of the PI.

You have one person who is the 'product owner' who has ultimate say on which items are in and out (usually the PI), they have to be involved right at the start to lay out the vision and setup a product backlog - just a brainstorm of ideas, roughly prioritised. If they have the time then they should also be involved in the sprint planning, but in reality we often have a 'proxy' product owner who plans the sprints and is involved in stand-up meetings to answer any questions about the requirements - in small projects this is usually the PM. The PI then still needs to come to sprint review meetings to follow the progress and direction as often as they can.

If you have a short, regular meeting setup once every fortnight or so then usually the PI can commit to that, and they don't get overloaded with ad-hoc questions.

gvwilson commented 7 years ago

Closed by 9b29434