Learning to walk is hard, but with support it becomes easier and easier. Before you know it, you're up on two feet. You've taken that first step.
It's the same within a company - If a company has a framework that nurtures staff, you end up with a more productive workforce. If not, there's a good chance that the staff are just going to move on.
This is why Agile, and the associated frameworks such as Scrum, are important. The first item on the Agile Manifesto is that individuals and interactions take priority over processes. Prior to our transformation, Aquila Heywood did not have such a focus on the individual.
So how did we do it?
Scrum was developed to improve processes and so the Development teams within the Technology department were deemed suitable candidates to begin the transformation. After a two-day 'boot-camp', the teams were restructured in the following ways:
Team Leaders were replaced with Scrum Masters. There's a huge difference between these two vocations, but the easiest way to sum it up is like this:
Team Leaders work for Management: Scrum Masters work for the team.
The main part of the team consists of the developers, a tester and a Product Owner: basically, the makers, breakers and takers of what the team is building. At the Redhill office there was an extra, non-traditional element in that the teams also contained Business Analysts. Aquila Heywood's AdministratorTM platform is a Pensions Provider tool and, as such, has a good deal of domain knowledge regarding the calculations and financial processes within it. The Analysts have on-hand experience using such knowledge from the perspective of how it is utilised in our software.
2. Work Process:
We traded in our clunky business and technical specifications for lightweight 'user stories'. These consist of a simple description of what's needed and what can be built, which is demonstrated to stakeholders and then changed if needed. Automated tests replaced inefficient systems of manual testing and retesting. As each story has a deliverable business value, this means that release times can be reduced. In comparison, previously large chunks of new product would take months, if not years to complete. Stories are of a size such that the team can build the new functionality within a sprint, which is normally a two-week period.
But the building of small-scale pieces of value does not lead to reduced release times by itself. Before transformation, we installed, configured and deployed our environments manually. To be more efficient, these would have to be automated. Multiple scrum teams also meant multiple environments, with the same configuration and installations that would have to change and evolve constantly. These, among other behaviours, are part of what's known as DevOps principles: a way of evolving infrastructure so that it fits in with Agile working methods.
The change here can be summed up in three words: Communication, Visibility, Empowerment. Before the transformation, developers would tend to be assigned a piece of work and then work on it in isolation. Teams rarely knew what other teams were doing and certainly had no idea what individual developers would be working on. Often, individual team members would not know what their colleagues in the same team were doing!
These were the changes that were implemented, to move the Company toward the nurturing of individuals and improving the quality of the product that it was delivering.
In the next part of this blog, we will see how these 'baby steps' were undertaken: the trips, the falls and the eventual first proper strides, made along the way.