We are now in sprint 3 of the project that we talked about in our 'Project work in progress -- Part 1' blog; with a few solution design sessions and sprint reviews now under our belt, this seems a good time to share an update on what we've been doing and what we've learnt along the way.
Solution design sessions
Before starting sprint 1, we discussed the sprint process as a team and decided that all disciplines and the client should input into the design of the platform; combining business knowledge, understanding of users and their objectives, and creative and technical input would enable us to design the most innovative solutions we could for the budget. We also felt this would help the team to get to know the client and their users better, build trust and make the decision process really open and transparent. This approach has worked really well for us; here's the process we've gone through:
Before the sessions, our User Experience expert gathers relevant personas and user journeys, reviews competitors and finds design inspiration. They also produce content requirements that ensure the design covers the user and business needs for this area of functionality. In the last iteration we split these requirements into 'essential' and 'non-essential' to help us focus more on the most valuable requirements, and to provide a starting point for validating any assumptions with the client.
After presenting the above as inspiration, we move straight onto sketching. At this stage any ideas are worth exploring, and a multi-discipline team brings plenty of varied experience to the table. Some ideas are later changed or discarded, but by exploring them all we're able to gain a deeper understanding and, ultimately, produce a better solution.
We consider all devices as part of the solution, so we sketch variations for desktop, tablet and mobile and develop patterns for mobile and tablet in early sprints that we carry through and refine. The designers work on creative for each page or component across devices before moving onto the next.
For a project with a limited budget, it's especially important to agree the minimum requirements for a viable product and focus on delivering those first. Many more ideas came out of the sessions than could be built within the budget, so there often has to be a prioritisation and simplification step built in where everyone agrees on what the best solution is; the other features and ideas can be captured in the product backlog to inspire future development.
Once we've agreed on a solution, we check it against the content requirements and user journeys to check nothing has been missed. We then go away and work up the sketch in a bit more detail before getting approval from the client and planning work for the following sprint.
- Cross-discipline design takes more time initially, but makes the build phase efficient -- and the end product better!
- This works best if all the key stakeholders and knowledge experts are at the sessions and willing to make decisions.
- It's vital to be really clear on what the MVPs are before moving into the build phase
Another part of scrum that is key is to review and then release work at the end of each sprint. This ensures that the team's focused on a clear goal -- to complete and show the functionality agreed at the start of the sprint. It also helps build the relationship with the client, clearly demonstrating that progress has been made and also helping them to feel part of the team.
Again, some of these sessions have worked better than others, here's some highlights...
In sprint 1, we had a complete section to review with the client, all functionality and front-end styling completed; the expectations were clear and the review went really well. In sprint 2, we had agreed to complete the back-end functionality, but scripting for this section ended up continuing into sprint 3. Having incomplete functionality at the end of a sprint caused some confusion, and User Experience, design and developer resource had to be carefully managed to ensure the team could stay in sync to complete a single set of goals.
As other commitments can get in the way, it's sometimes necessary to do the sprint reviews remotely. When this is the case, we've found that Google hangouts work well, allowing us to share a screen but also see and hear reactions from all parties. We all agree, though, that the quality of feedback just isn't as good this way; it's much better when clients can play with the experiences we've created themselves and discuss face-to-face. Being in one place together, reviewing the site as it develops, also makes us feel more like one team and is far more effective.
- The team needs to be kept in sync -- we have found design working one sprint ahead of development works best.
- It's best to get the team and the product owner in one place for sprint review if at all possible.
- It's always worth doing sprint reviews -- even if they're not perfect.
As with all things at Code, we look to review and refine the process through retrospectives and open feedback, so things will continue to evolve with each new sprint, project and client.
In the next post, we will look in more detail at what we've built so far and share some of the technical choices we have made around the infrastructure, releases, Umbraco, MVC and Elasticsearch.