The moment you, as a manager, mention the word 'process' to a development team, you can almost hear the collective sigh.
Historically, managers will swan in and implement a brand new process purely to serve themselves at the detriment of the team's productivity. This is definitely a cynical view, of course, but throughout my career, I've worked with many developers who have thought and felt exactly this way.
To contrast with the admittedly cynical view of managers, here's a cynical view of developers: developers are notoriously resistant to change, and the implementation of a brand new process is ostensibly 'change' that will affect the day to day productivity of the developers.
This cynical soup of adamantly change-resistant developers mixed with self-serving, technically ignorant middle-managers gives a rather dark view of the success and productivity of a development team. This is not the well-oiled high-performing team we all strive for. No disrespect to either developers or managers, since I am both and I am immersed in the world of both; I know these struggles all too well.
The truth is, whilst this is a cynical view, each side often believes the stereotype of the other, leading to strong rebellion, or at the very least, a struggle to engage wholly within the newly established process. This then becomes problematic for both the well-intentioned managers and the productive developer.
So then we, as managers, need to tread carefully when implementing processes. I've had my fair few missteps in this domain, so I hope to offer my experience as a caution to budding development managers in the tech community. To fully illustrate this, I'll talk about everyone's favourite agile framework, Scrum.
I have qualified as a Certified ScrumMaster® in the past, and as a result, I am an advocate for Scrum, therefore, you can imagine me typically pushing forward with implementing Scrum processes in a fledgeling development team. If you're doing this right now, you need to... and I can't stress this enough... stop everything you're doing.
Scrum is an excellent agile framework, however, Scrum is not a solution to all that ails your team. Scrum is bulky, and heavy on the process. Anyone who has gone through Scrum training will be mildly triggered by that assertion, since as the text-book suggests, Scrum is "not about the process, and puts the people and ideas first", but in the same vein, the trainer will assert that you can't and should not deviate from the text-book process. So there's a very clear process, and this process is not for the sake of process - that's a difficult sentence to comprehend. I get it, I'm a Scrum advocate, I know how to do it right, and I have personal experience to attest that Scrum is not for every team.
Scrum is designed specifically to solve a series of common problems in development teams. However, not all development teams will suffer from the problems that necessitate Scrum. Teams of less than four members, teams with a hands-on or highly responsive development manager, teams with a well-established flow of tasks, or with senior management team that's close enough with the tech and the team itself, will not necessarily need a process and framework as bulky as Scrum. To implement Scrum in these situations would be grossly over-processing the team - even if you implement it correctly.
Adopting Scrum because "it's what everyone else is doing" is simply not a good enough defence for the potential missteps and difficulties you're placing on a team. This isn't just caution against Scrum, it's a caution against every possible type of process you're thinking of introducing. A process should be implemented carefully, and you should deeply consider the need before you leap into it. For this, I have a golden rule:
Processes are designed to solve team problems. If you cannot point to the problem you're solving, then you shouldn't implement the process.
This doesn't just go for the Scrum framework as a whole, but in my opinion, should also go for the sub-parts of any such framework. For example, if your team communicates well with the manager and amongst themselves then I would posit that you don't need a Daily Standup, and implementing such is nothing more than a needless ceremony. There then exists no 'problem' within your team that a Daily Standup would be solving. So get rid of it.
What happens when you encounter resistance to your process from your development team? Simple; you point to the problem and describe how it affects the team, and what the potential pitfalls are of not implementing it. It becomes an easy argument to make. If you're not solving a problem, this argument is impossible, and your process will suffer within the development team.
This article is not merely meant as a denigration of Scrum - it's a process that I hold dear in my heart, but is simply a caution. Take your time and build a case for why you need a process, before launching into it. Centre in on the problem you're trying to solve and endeavour to find the best way to solve the problem itself before you think about implementing one of the big system processes like Scrum. This is the only way to ensure adequate buy-in from your development team, and superiors alike, and the only way to successfully implement a process.
Top comments (0)