What does everyone mean
when they say Agile development?
You may have heard the Knowledge team talk about booking work into a ‘Sprint’ or discussing it in the ‘product backlog meeting’, so I thought it would be a good idea to sit down for a few minutes and explain what it all is, and why we describe ourselves as an Agile development unit using Scrum framework.
Companies have long employed development practices like Prince2 or Waterfall to create systems, but I find this a little restrictive, particularly when working in IT where the landscape and requirements change frequently. Agile is a project management philosophy that priorities early and frequent increments, allowing for changes throughout. Scrum is the framework that guides us through this. Scrum defines how we identify the work needed, who does the work, how and when it will be released. Agile and Scrum are a perfect partnership here, allowing us to be creative, regularly release updates and continuously move forward in developing EDGE.
We are always on the lookout for great ideas for functionality, these ideas form a list that we refer to as a Product Backlog. We can’t build everything at once so we make sure the Product Backlog is prioritized and under constant review so when we do meet with development, we know exactly what we want to build, how it needs to work and what should be done first.
While most updates are released monthly, internally we work on a two-week development sprint. Having a two-week sprint means our developers have a pretty good idea of what they can complete in the timeframe and this work becomes our sprint goal. The Sprint goal is set between our Product Owner and the development team. We agree this as a team, everyone is involved in the decision and therefore committed to the goal. We don’t have a lot of rules in scrum but there is one big one: The sprint is a locked event – no interruptions. As you can guess, interrupting the team mid-way through throws off their focus, leaves them less time for their original work and mild chaos ensues. It is probably one of the most difficult things for us Knowledge officers to do, we are always asking for “just one quick change?”, “just one little import?”. Anyway, that’s the rule and we do our best to stick with it.
At the end of the sprint, we have meetings which are called Reviews and Retrospectives, in short this is our chance to look at what we have achieved, make sure we are happy with it and for us to think about the sprint itself. Did we do everything we could, is there anything we would change next time? It’s this part where you see Scrum and Agile ideas blending again, the aim is continuous improvement. We aren’t going to try to build Rome/EDGE 3 in a day, but with small changes, tweaks here and there, and open discussions, everything keeps moving in the right direction.