First off, before I make a lot of people very angry with me, I just want to state that I love scrum as a project management methodology to manage work. But I believe that scrum on it’s own is not a mechanism to achieve true agility in delivering quality working software to your users.
Part of the power of Scrum is the approach to the planning of work. In the teams I have worked in, on a weekly basis we have groomed stories from the product backlog, which has been prioritised by the product owner. This allows us to have a view of the upcoming work, to discuss what needs to be done and to plan the pieces of work in the correct amount of detail.
Following on from this, scrum allows you to break up large pieces of work into manageable junks. These junks can then be delivered within a short period of time. This for me is a great benefit, because if you are delivering software every one to two weeks, even if it is into a staging environment, the team is achieving small wins often.
The product owner is also entitled to re-prioritise the product backlog in line with the changing needs of the business. This ensures that the team is always working on changes that are relevant to the business. And, because the changes are small, the team is able to adjust to the changed priorities far more rapidly than the traditional waterfall project management methodologies.
Scrum also elevates communication within the team. This is facilitated via the daily stand-ups where every member of the team has the opportunity to feedback on three aspects. Namely, what the team member did yesterday, what the team member is going to do today and does the team member face any impediments. This highlights issues early. If the same impediment is raised over consecutive days then it can get escalated or an alternate approach can be found. If a team member is stuck on a task for multiple days then a colleague can jump in to assist or alternative approaches can again be found.
So implementing an agile project management methodology, such as Scrum, is a step in the correct direction, but to become truly agile we also need to revisit our mindset around how we physically deliver software. This is where technology and practices come into the picture. In my opinion, the most important mindset shift is one towards Lean Software Development practices. By embracing Lean Software Development practices we are able to identify areas of improvement that allow us to achieve agility.
For me, a measure of a teams agility is how easily and how often they are able to deliver software that is valuable to the business and is of appropriate quality into production. To achieve this we cannot have manual regression testing, manual builds or manual deployments. The team also needs to have visibility of how changes, once deployed into production, are behaving.
To achieve this, firstly, the team must automate as much as possible. From automated unit tests to automated builds to automated acceptance testing. Secondly, the team must ensure that the infrastructure that they are deploying to supports deployments at any time of the day. This leads to a need for a level of redundancy in the production environment to allow for deployments at regular intervals, at anytime of the day and, most importantly, without impacting the clients using the system.
This requires that practices such as Test Driven Development or Behaviour Driven Development are embraced by the team as a whole. This is where, I believe, the role of testers starts to change in the team. They should no longer be manually testing systems, but should rather be assisting the developers in automating any changes that are made to the system. This frees the testers up to add input regarding quality throughout the development cycle, from analysis through to delivery.
Along with TDD or BDD by implementing Continuous Integration, the developers are getting feedback often with every check in, without having to do extensive manual testing to confirm that a change is indeed working. Once these practices are solidly in place the team can move to the ultimate delivery cadence of Continuous Delivery, where changes are deployed to production on a successful run of the automated acceptance tests. This is something I have not achieved in my career, but I am certainly striving to get to this point.
The last point that I want to discuss around achieving agility as a team, is the dev-ops movement. I am a firm believer in Werner Vogels, the Amazon CTO, statement of “You build it, you support it”. Not only is this an incentive to maintain exceptionally high standards in the development cycle, I certainly don’t want to get woken up at all hours to support a buggy piece of code, but it also reduces the feedback cycle. The individuals making the changes are immediately aware of the impact their changes are having on the system, whether good or bad.
The dev-ops movement also eliminates the us and them problem that often arises between development and operations. And it ensures that efficiencies are achieved in the delivery of software into production. One example, that I have experienced in my development career, is the need for documents to describe each and every deployment into production. This is wasteful and should be automated, but because of the trust divide between operations and development often is not.
So if you have successfully implemented Scrum as a project management methodology in your organisation, well done. But don’t stop there, couple Scrum with Lean Software Development and Dev-Ops and you will truly start to achieve agility in delivering valuable software to your clients.