This is the sixth part of my blog mini-series of things university doesn't teach you about being a software developer.
To keep a business functioning effectively, you have to make sure you're constantly tweaking, making adjustments to how things are done, improving the way you work. In any competitive market, any company that stands still is doomed to fail, maybe not straight away, but sooner or later.
A well-run development team is very similar; in this still relatively early age of computer science and software engineering, we've not hit upon the perfect way of delivering software, the optimum set of processes… and we probably never will. So much depends on the circumstances, the objectives and the skills you have available.
Thing 6 - Thinking retrospectively
Reflecting on work and figuring out what you could have done better is key to continuous improvement. This is true of essentially all work, and life in general.
In software development, this very often takes the form of "a retrospective" - a specific meeting, but it's also essentially a mindset. You really should think this way all the time.
Part of the mindset is insight - spotting inefficiencies in the way you work so they can be addressed - and part of it is, ultimately, practise. The more you think about your processes, the better you become at critically analysing them.
What is a retrospective
Perhaps, the most key component of effective agile working is regularly holding "a retrospective", a meeting in which you reflect on recent work and discuss, as a group, how things went, with a view to improving future performance. It should be no surprise that this is the final principle of the agile manifesto:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
So how does "a retrospective" (the meeting) actually work?
It varies from team to team, but the over-arching format should look to ask questions like:
- What we did well
- What we didn't do well
- How could we improve next time?
These questions are typically scoped to the length of a sprint (i.e. a two-week period of development work), but realistically you can hold retrospectives as often as you want to.
Another effective set of questions I've seen used comes from the team at Cucumber, who presented their Mob Programming retrospective strategy at QCon 2016 (video):
- What did we do?
- What did we learn?
- What we decided
- What still puzzles us?
In both cases, the questions asked are both quantitative and qualitative. Those involved are asked to think carefully about every step, criticise, analyse, and think ahead for the future.
What makes an effective retrospective?
There are a few things that are key to running a good retrospective session…
Firstly, it must be chaired by someone who will keep things moving along, rather than descending into uncontrolled discussions. The point of a retrospective is to identify problems and come up with solutions, not to discuss everything in incredible detail. If the meeting takes more than 30-40 minutes, put down an action item to run your retrospectives more effectively!
Secondly, you need to quantify the feedback. If you're using post-it suggestions from everyone involved, you could use affinity sorting to help organise and understand the importance of each topic discussed.
Thirdly, you must take down actions that are reasonable to try and address in the next sprint (or other measure of time). You shouldn't see issues coming up again and again in retrospectives, otherwise you're not continuously improving, you're just continuously moaning.
Regardless of the questions asked, the most important thing is that everyone feels they can speak their mind, they can contribute anything they like to the conversation. A retrospective where anyone is afraid to say what they're really thinking will be an ineffective waste of time.
Why this isn't taught at university
As I've written before, university coursework lends itself to short-term-ism; it's a lot more like throw-away prototyping than any actual work. The need to improve isn't really there because you move on to something completely different and never look at your old work again.
It's also notable that although you'll likely be assigned a personal tutor for the duration of your university career, in my experience you hardly spend any time with them whatsoever. I think I spoke to mine a total of two times. Almost every other member of staff you interact with is more transient. You'll get different lecturers for each subject, and there's no cross-coordination of how well any one individual is doing.
Of course, independent learning and study is part of university, but there could certainly be more done to track progress and reflect on how to improve the quality of work of a student over the three or more years that they attend.
How could this be introduced?
I'm no fan of forced group work, but regardless of how work was undertaken (individually or as part of a team), there's a huge amount of merit in reflecting on what you've achieved. However, in situations where forced group work has been inflicted, then it would make sense for retrospectives to be run on a regular basis. I would suggest that lecturers or PHD students run these sessions as facilitators to make sure that they happen, and to assist with sensible actions.
Where work is performed individually, it's still reasonable for students to get together in groups to discuss how they're getting on. Again, this could be facilitated as above, but even if it's not, it's a useful thing to do independently.
In addition, I would suggest that lecturers or mentoring PHD students could run mini retrospectives at the end of lab sessions to summarise the lesson and to get useful feedback for next time. Lab sessions themselves provide a chance for students to iteratively improve their understanding of a given topic, and it seems wasteful not to actually check this is happening as effectively as it could be.
What should universities take away from this?
Too much of university tuition is "fire and forget" - students are set a piece of work, they do that piece of work, it is marked, and then they move on to something completely unrelated and never take the time to properly reflect or improve. Some students may be naturally introspective, but most probably won't. I certainly didn't think too much on any reasonable grade, even though in hindsight I could have improved my own personal performance quite a bit by doing so.
It's well worth thinking about teaching general agile principles, but certainly running and facilitating good retrospectives will help students reflect on their progress, come up with ideas on how to work more effectively next time, and could even provide useful insights as to how course material can be better delivered.
Students can, and should, be giving feedback to their university, and it must be listened to. With tuition fees ever more expensive, lecturers are surely under more pressure than ever to deliver top notch teaching.
What should students take away from this?
Try to make yourself work in short bursts or sprints, even if you're working individually. Think about how you can improve, but don't forget to note down what you did well. Discuss with your peers. Make solid plans to help you do better next time.
Thinking retrospectively is a core component of agile - you will very likely be using agile methodologies as a software developer (or you should find a better job) - and the more practise you have, the better you'll be.
Personally, I think Woody Zuill put it best with this tweet:
If you adopt only one #agile practice, let it be retrospectives. Everything else will follow.
Next up
Next time I'll be talking about consuming APIs and libraries, how university doesn't really delve too deeply into those subjects, why that's a bad thing, and what you can do about it.