I think we are at the moment when agile methodology is a de-facto standard in software development (at least in the web development). A lot of people have questions to this approach, and I am one of them – I like to challenge ideas, so I’d like to reflect on my experience, analyzing what went well and what did not. Using agile vocabulary, I’ll conduct a retrospective over the whole topic of processes.
In the beginning of my career I worked in a very small digital agency in my small town, and nobody even heard of any of all that agile stuff (neither did I). However, looking behind, some principles still applied – we did iterations, we tried to get early feedback, we had to welcome changing requirements (even though welcome is not the best word here), and our measurement was exactly working software. We did not do some things, like retrospecives, and I admit it would improve a lot of things.
My next job was in a much bigger company (I think around ~80 employees), and some teams were actually doing development using agile principles directly. I worked shortly there, and felt a little bit awkward, especially during the rituals, and could not get why should we postpone some questions, estimate things by people with different knowledge and always act as a team (so forming smaller groups for specific discussions was almost prohibited) – some time after I got it, but I still have a lot of questions.
I mostly worked in another team, where we did not have proper processes, but we had a lot of clearly defined tasks, which were independent for different team members, and deadlines (which were also different for different platforms). API was ready and very well-documented, so common interactions were not necessary. Syncs were rare (I’d say about once/twice per week, and “global” once per month), and it allowed us without all that overhead to deliver a lot and to meet deadlines. But after initial release, wnen we started to create new features, it bit us back, and we had to spend some time to build the processes for more effective communications.
Since then I worked in bigger and more serious companies (also, I believe agile made it to the industry standard completely), and it was full agile. It was different flavours – Scrum/Kanban/maybe something else, but all of them were pretty dogmatic, with very different prospectives what actually agile is and how we should work. The single thing, which unites all of them, is how strictly we followed rituals.
However, as soon as we had a lot to do, almost any team leans to change pace of working, carefully choose people who needs to be on meetings, question meetings in general (“do we actually need it?”), and skip/do less rituals. This empirical data fits perfectly into Parkinson’s law:
“Work expands so as to fill the time available for its completion”
To conclude, my experience is that everywhere I worked, everybody had different opinion what agile/scrum/kanban is (there is even a term “Scrumbut”).
I’d like to bring description of processes in my second workplace once again:
I mostly worked in another team, where we did not have proper processes, but we had a lot of clearly defined tasks, which were independent for different team members, and deadlines (which were also different for different platforms). API was ready and very well-documented, so common interactions was not necessary. Syncs were rare (I’d say about once/twice per week, and “global” once per month), and it allowed us without all that overhead to deliver a lot and to meet deadlines. But after initial release, wnen we started to create new features, it bit us back, and we had to spend some time to build the processes for more effective communications.
I did not understand that at the moment, but now I truly appreciate that I worked in a team where everything worked just fine in the beginning, and allowed us to actually deliver on time and focus on the features with maximum productivity, but later it made it very hard to proceed with development, which started to require close collaboration between different members, and we had to develop new processes.
Does it mean, though, that these processes should be implemented from the beginning? No! Maybe earlier, but definitely not from the start – I truly believe it would slow us down at the moment and would raise a lot of questions, why do we do it all. It also brings another point, that there are no best processes, rather what works good enough for your specific case, and you might have to experiment before finding it, and any changes later can ruin old dynamics; therefore, you should not be afraid to rethink your approaches.
The outcome is extremly simple: what works for small team with one requirements, does not work for a bigger team with different requirements.
Reading through this article, you might get an impression that I am against agile per se. That is not the case – I am just against cargo culting, and agile practices pretty often resemble them: no allowed changes, ideas very often taken from somewhere else, no discussions.
Agile manifesto is actually a very good read, and would improve any team’s workflow after reflexing on it – but I think it should be more “agile”, so that we can pick statements which fit our flow, and adapt them to the current situation. There are a lot of variables, and at the end you work with people, so some things might not work with specific people, and you should consider it while defining your processes.
However, I am skeptical that the fact that agile is de-facto standard in the industry tells us something good about it all – actually, I think there are two main reasons why it works:
I think it makes sense to experiment and try to adjust processes depending on the team dynamics and requirements, and in case of finding it, not to just use this model forever, but to reflect and try to improve it over time.