Yes, of course it is! Scrum is a framework to help teams and organisations on their path to agility, but it is by no means the only way to be agile.
Back before I knew about Scrum, I worked on projects that were agile. Back then we didn’t really know what agility was all about, but that didn’t mean that it sometimes didn’t occur naturally. We just didn't make a conscious effort to be agile, as most organisations do nowadays.
One project that I worked on many years ago did not use Scrum, yet was very agile. The project was to build a large and very well known newspaper website in the UK. It was characterised by a few key factors which I will explain to highlight our level of (unaware) agility.
Small Is Best - Time, Scope and Team
The project was deliberately kept small, both in terms of scope and the number of people involved. Despite it being a potentially large project, the time scale was very short and we had to deliver a new product within a fixed 3 month deadline. To do this the business rightly realised we had to strictly limit the scope of work and focus on the most important things first in case we ran out of time.
Scope was fixed and relatively small and was kept this way to give us a hope of success.
We had only 3 Developers on the project and 1 Product Manager from the business working closely with us on a daily basis. Resources were fixed and would not change throughout the initial delivery phase. We had to make do with what we had.
Clear Requirements
We had very little in the way of written requirements. There just wasn't time for this. Instead we had 1 person (our Product Manager) representing the needs of the business and the future users of the product. They sat with us Developers and were on hand every day to speak to us and answer any questions we had as we were working.
Responding to change over following a plan - Manifesto for Agile Software Development
Regular Planning
We did very little in the way of formal planning, but every Monday morning we would all meet and discuss what we hoped to achieve by the end of the week. Our Product Manager would attend and remind us what the most important things were. We would work on those and complete them first.
As a small Development Team we sat together and spoke about what we were doing and how we could help each other. We did this all day every day. It came naturally as we had been working together for many years and had got used to doing this over many previous projects.
Regular Reviews
Customer collaboration over contract negotiation - Manifesto for Agile Software Development
At the end of every week we would get together informally and show off what we had done. Our Product Manager liked seeing what we had been working on throughout the week all working together in one place. There were no surprises for her as she saw what we were all doing each day whenever we had a question or wanted some clarification over something. As and when things were done during the week we showed her what was ready and sought her feedback.
This close contact meant that we were always delivering what the Product Owner needed and didn’t risk going off at a tangent, wasting time creating the wrong thing.
Regular Improvement
We didn't hold formal retrospectives, but whenever someone found a way to do something better we talked and shared. Whenever someone had a problem we also talked and sought help. We never really stopped talking and sometimes it was a wonder we ever got any code written!.
But this information sharing was very useful. On one occasion I was about to start a 1 week piece of work. On checking in with the Developer sat next to me over coffee, I discovered something similar had been created on another project. I was able to reuse it and saved myself 4 days of pointless wasted work. Talking was good!
A Cross Functional Self Organising Team
All the Developers in the team were of a similar level of experience and were classed only as 'Developers' by the organisation. There was no hierarchy in the team. There was no one else around to tell us how to do things, as no one else knew how to do it. Our manager was busy working on another critical project and had no time free to help us.
Individuals and interactions over processes and tools - Manifesto for Agile Software Development
As there were so few of us we were all expected to do any and all tasks required to produce the finished software. This included business analysis, architecture, writing code, creating environments, managing the database, testing in all its forms and release activities to put the software into production. We were the very definition of a cross functional, self organising team before we even knew what such a thing was.
Quality Is Key
There were no dedicated testers. The organisation believed it couldn't afford them. As a result, we were all responsible for the quality of what we produced. We also knew we would have to deal with the consequences of any problem code going into production, as we also had to support the site once it was live. There was no support team to pick up the issues that we created and there never would be one. As a result, we created very few live issues, and where they did occur we fixed them as a priority so we could be free to continue developing new features, rather than supporting a failing production system.
Regular Releases
Working software over comprehensive documentation - Manifesto for Agile Software Development
With no dedicated release team we had to put our own work into production. We did this daily until the site went live and because of this we got really good at doing releases. As a result, even once the site was launched we continued to release at least a few times each week, which kept our Product Manager happy as she could get new functionality as soon as it was ready. It also helped us as it meant we didn't have to deal with the complexity of branching strategies and integration became a small and trivial task.
So Did We Need Scrum?
Looking back I now realise that this all looks a lot like Scrum, albeit without the formalities. Without meaning to we stumbled across the secret to successful software product development. So did we need Scrum? In this case we did well and were agile without it. However many other projects at the same organisation were not so successful and the failure rate was still high. The organisation would have benefited from Scrum at this point as it would have led some of the other Development Teams to some of the solutions we had found naturally.
The organisation did go on to implement Scrum throughout a few years later. For my team, it seemed easy. We were already doing most of it without having the formal rules in place. The addition of Scrum just made sure we formalised what we already did, picked up a few new tricks (Definition of Done and a more empowered Product Owner) and made sure we didn't forget some of the really important stuff we were already doing. For the other Development Teams it made a huge impact quickly and enabled the organisation to produce many more market leading products and scale their development efforts successfully.