Collaborative working
Two minds are better than one, and during the previous sprint our team was able to put this old adage to the test. By working together through pair programming, as well as holding discussions between content, design and development teams, we were able to complete a number of complicated tasks while improving the quality of our current projects.
These successful pair and group projects have taught us that working collaboratively often yields far better results, and we are now pushing to be able to work on more tasks together.
Jenny and Peter explain some of the ways we were able to make things better together:
Revamping the subject pages
Written by Jenny
The content team has spent the last two to three weeks reviewing and updating the content on the subject pages. During the review, we noticed a number of design and development niggles that bothered us. Working with the front-end of these subject pages allowed us the advantage of seeing how different types of content, as well as varying lengths, looked on the page. These were problems that couldn’t have been planned in the original design, and which the development team missed when working only with the back-end.
Unsure whether we were overstepping our remit, the content team tentatively mentioned these problems during a sprint retrospective. However, both design and development teams happily jumped on the request and invited the content team to come and explain the problems to them.
On behalf of the content team, I sat with Lewis, Peter, Duncan, Aaron and Steve to point out some problems within the layout, spacing and navigation. It was a very productive conversation that resulted in a revamped look for the subject pages. Design and development will work on the new patterns and look for these pages in the coming months.
Only by having this cross-team conversation were we able to come up with a solution that will make these pages much more engaging, unique and functional.
Pair programming
Written by Peter
The development team are currently working on a project to complete our digital pattern library: a collection of design patterns we offer to the University’s developers for use on their websites.
This has required us to review our code making sure it meets our code standards, follows print guidelines, and is fully accessible. We decided that to achieve the standard we were aiming for, it would be more productive to work in pairs.
When ‘pair programming’, we have one team member coding (driving) while the other keeps an editorial eye on what is being developed (navigating), making sure any work done is bug free and that all spelling and syntax errors are noticed straightaway.
We’ve found this to be very effective, since the second team member is focused solely on quality control. So most, if not all, bugs are picked up right there and then.
We do of course still have our QA process, which should pick up any stray mistakes that the pair may have missed.
Not only has this ensured an increased quality of work, but problem solving is easier when there are two minds at work. So we were able to resolve puzzling bugs much quicker. We will definitely be continuing this practise with our future projects.