Although I am not in software development, and I don't work in a lot of teams, I have recently read the book Scrum: The Art of Doing Twice the Work in Half the Time (https://www.scruminc.com/new-scrum-the-book/) which I find very interesting and possibly quite useful1. As far as I can tell, the Scrum process derives its value from a few key concepts, which can equally well apply to individuals as well as teams, to academia as well as software development. These key concepts, as I see them is,
- Work is done in a short, cyclical pattern: 1-2 week "sprints"
- The work - the goals, on deck (aka backlog), work in progress, and done - is displayed publicly (or at least prominently to the team) at all times. This is typically done with a physical scrum board, but can also be done in software.
- A demonstration occurs at the end a work "sprint". The result of the sprint is something deliverable and complete, even if small, and this is demonstrate to the people to whom the work has value.
- A review of the process and results occurs regularly at the end of each sprint
If working on a team, we add the further concept
- A team needs to have absolutely everyone who is needed to complete the work. This will often involve people at many levels of a hierarchy.
As an addition, there are a few other things I learned from the book.
- The role of management is to remove the impediments to getting projects done. So, part of the review process is to list the impediments to the work so that management can work on that.
- Short (15-minute) "scrum" meetings answering "what have I done since the last, what are my impediments, what am I going to get done"
- Focussing on value rather than work is more productive.
- The "deliver quickly" and adapt is a better strategy than trying to deliver a large, complete, and possibly incorrect product.
Meanwhile I am also working my way through the book Agile Faculty: Practical Strategies for Managing Research, Service and Teaching. (http://press.uchicago.edu/ucp/books/book/chicago/A/bo26106581.html) I'm interested if any of these ideas will help in my own practices, and whether I can gain some benefit for the department and university processes with these ideas.