I’ve been a professional software developer since 2002 and worked for several software companies over the years - some practiced Scrum, some used Kanban, some had a tailor-made methodology and some didn’t have any methodology in place.
When starting with Agile a few years ago I found out that:
“All waterfall companies are alike; each Agile company is Agile in its own way.”
Over the years I learned to classify each company’s methodology using two factors:
- Ceremonies – whether the company follows the methodology practices – iteration planning, retrospective, and/or daily stand-ups.
- Intent – does the company understand Agile values, strive for continuous improvement, quick feedback and embrace change (among other things).
And so I bring before you the four types of Agile companies that I had the pleasure (in most cases) working for in the past:
Neither ceremonies nor intent (Aravah)
I got to work for several companies that had no visible software development process - or had a process which made no sense.
It doesn’t necessarily mean that those companies didn’t have a project management “methodology” – in one case we had a whole division “planning” and “tracking” the various projects. Unfortunately the beautiful charts and predictions never affected us developers, and other than reporting (read: lying about) project hours it didn’t bother us much.
It was chaos incarnate – no one knew what was going on. Some of us were overworked while others would drink coffee all day. After finishing each task I had to ask my manager what to do next and from time to time we’d ship a product.
And so we worked hard on fixing bugs and implementing new features without real understanding of the overall picture.
Ceremonies without intent (Hadass)
After a few years I got to work for Uber company Ltd. (if you know me you might know which company I‘m referring to). We created a new shiny project that just had to succeed (at least until it got cancelled), and as such we needed to use the latest and greatest of everything - including a new methodology called Scrum.
Consultants have been hired, courses have been taught, developers and managers were trained and a lot of money has been spent to make sure that the project would be a great success.
I was hired a few months after that and when I got there all that was left was the bills and a daily meeting that took between 30 minutes to 1 hour – which for no particular reason we had to do while standing.
My educated guess is that the company refused to change its ways and so all that was left were the ceremonies: the daily meeting, planning that was done first by the team, then by managers and finally not at all, and retrospective that happened three times during the year I worked there.
Intent without ceremonies (Lulav)
In one of the last companies I worked for before becoming a consultant was a team that knew about Agile – the manager had experienced Scrum before and wanted to us it to build software. He had a clear understanding of what he needed and wanted and how to achieve it. He had Scrum custom made to fit his vision and while some of the benefits were lost on the way the underline values were always there.
Since the team was willing we were able to add daily meetings, retrospectives, and backlogs. And while the company never really wanted our iterations we were able to build a methodology very similar to ScrumBan that made sense for us.
We had TDD, task boards (plural) and clear priorities. We managed to create value for our customers – fast while reducing technical debt.
It was not always simple or easy but we all had the same goal and so were able to find tools and methodologies that worked for us.
Ceremonies and intent (Etrog)
This is where I became an Agile addict – this utopian company decided to go with Scrum and managed to stick to that decision.
When we noticed that Scrum didn’t make sense for customer support we used Kanban for open tickets.
After doing Scrum by the book for more than a year we knew where we needed to adjust our methodology and what we needed to keep on doing (retrospectives). We experimented with different iteration lengths, we had XP practices (pair programming, CI, TDD), and continuous deployment.
We managed to be productive and effective. We had management that was willing to provide us with time to learn and much needed feedback.
There you have it – four types of companies based on my (limited) experience – some were successful and some failed miserably.
If there is one thing I learned it is that you have to have intent and understanding in order to succeed with Agile – I got to use Agile in waterfall companies and I also saw bad Agile (and "no Agile") practiced even when someone up the corporate chain had decided that the company was an Agile company – the decision rarely left the board meeting if the developers (read: those who write the code) were not educated or in some cases even part of the process.