Big Sofa Tech Blog: Experiments in Agile

One of the biggest challenges tech teams have to contend with is change - from day-to-day changes in requirements and priorities to the ever shifting technical landscape of tools and approaches. 


To handle this continual change we try to be as “agile” as possible, trying to adopt an agile mindset by following the principles outlined in the Agile Manifesto. These principles focus on prioritising customer needs, responding to change and building a flexible and positive environment for teams to flourish in.


There's no right or wrong way to follow these principles! There are many different frameworks and practices that can help teams in different situations embrace change, but there's no silver bullet. Finding the best approach for any team requires a lot of experimentation.


At Big Sofa we have been experimenting with Agile for over 5 years. During that time, we've found success in some practices and failures in others. In this post, we'll go through some methods that worked - as well as some that didn’t!




Starting with Scrum

Like most development teams we started out with Scrum, a framework for developing working products by delivering features incrementally over multiple iterations or 'Sprints'. We began with 1 week iterations, which is quite short by Scrum standards but allowed us to focus on developing a small number of value-adding features. 



In following the Scrum process, we held the typical ceremonies of Sprint Planning (to discuss and plan the tasks for the iteration), Daily Standup (to monitor progress) and finally Sprint Reviews where we reflected on what we had achieved and suggested actions for the next iteration.


This process worked well, with the team delivering value each iteration. However, we did find there was an issue with estimation - we constantly overestimated the amount of work that could be achieved in 1 week and were often left with tasks to clean up from the previous iteration.


Part of this was due to the way we were estimating work using developer hours. Contrary to popular belief, it’s very difficult to accurately estimate time and our predictions didn't represent the range of experience and skills within the team. 


Reflecting on this we decided to try a new approach of estimation by using story points instead of development hours.

Points mean Prizes

Story points are an alternative method of estimating the effort and complexity of tasks by establishing baselines agreed on by the whole team. When all members of the team agree a task is worth 5 story points then they can estimate other tasks comparatively (e.g. this task is easier so it should be 3 points). 


After completing an initial iteration we had completed 60 story points worth of tasks, which then became our new goal for the next iteration. We frequently achieved 60-70 points, giving us confidence in what we could deliver and helping us to plan ahead.


Although we were continually delivering ~65 points of work each iteration we noticed that our larger projects kept dragging on. This led us to realise that the issue was not the amount of work being delivered but rather what was being delivered.


Our iterations consisted of tasks from multiple projects with developers switching from one feature to another. This context switching was increasing cognitive load on the team and meant we were losing focus of our goals. To fix this we needed to shape up the way we planned work.


Shaping Up

We took some time to research different methodologies and landed on the ideas suggested by the Basecamp team in their book Shape Up.


This approach focuses on delivering a meaningful feature/improvement within a 6-week cycle. During the cycle we continue to develop the product iteratively and release frequently, enabling us to get feedback throughout.


The work is “shaped-up” before the cycle. This involves key members of the team reviewing and researching the problem, which means that the team already understands the goal and has a rough plan for what needs to be done before we start development. We can then agree on a scope for the cycle.


Instead of estimating how many tasks we can do in the cycle, we think about what we want to achieve in 6 weeks. After 'shaping up', the team self-organises and splits the work into their own tasks which they manage and track. At the end of the cycle we then reflect and consider whether what we have is good enough for full release, whether it needs more time, or whether we should just park it for now. 


Following each cycle, we have a 2-week downtime period where the team can focus on experimentation, learning or refactoring old code.


Having trialled this method for a few cycles, we are now delivering better quality features in a more timely manner. In fact our recently released Playlist Studio feature was developed within a single 6-week cycle! 


Morale is higher as well with the team feeling empowered to shape their own solutions. We've also made great use of the downtime period too, spending this time experimenting with new technologies and delivering fun extra features!


We haven’t fully adopted the Shape-Up approach - we still have a lot of room for improvement when it comes to shaping the work. We’ve also kept parts of the Scrum process that worked for us, like the Daily Standups (although these are much more focused now!) and Sprint Review ceremonies.


There is no perfect solution to building software but we're confident that with a little experimentation we’ll get pretty close!

________________


In the next of this blog series, we’ll go into more detail about how we used this agile approach to rebuild our front end and API, so stay tuned for the next post in our Tech Blog series!

edit