Development methodologies have been a hot topic for a long time. Initially it was waterfall, then agile, kanban, and scrum. There are hundreds of variations on each of these and plenty of consultants to “teach” you how to successfully implement them.
The problem is that they don’t work.
As a developer and manager we easily get pulled into the promises of a utopian project management solution that will increase efficiency and produce a higher quality product. When the new approach fails, we hire consultants who tell us what we are doing wrong, make a few changes, and get the process to appear like it is running smoothly. Everything is just peachy… that is until they leave.
Everything falls apart and you feel you are back at step one.
Why does everything fall apart after the consultant leaves? My theory is that there is an inherent need to embrace this trendy new methodology because 1) you screwed it up and want to improve and 2) you are under the microscope to pick up the pieces. The consultant essentially rallies the troops and everyone is back on board with the theory.
Once the consultant leaves, you are left to fend for yourself — this is where developer’s real opinions come out.
Some love it, some hate it, some don’t care. The unification is gone and the implementation of the methodology falls apart.
Great developers do not like to be forced into a process that does not make sense to them. Overhead is the bane of any developers existence, and if your process feels that way, it will not be embraced. Efficiency is key, and that efficiency is driven by how they work, not what they produce.
So, what system is the magic bullet?
There is none!!! And stop looking for one!
To run a successful team, you must understand each individual. Group these individuals based on how they work, not what they happen to be working on. Let these teams figure out a methodology that works for them. Developers want to get shit done, so let them. When something goes wrong, encourage and entice them to figure it out themselves.
Just because a system increases your analytics, creates better reports, or allows for better tracking of projects does not make it good for the developers, who matter so much more than the process. If you don’t think that developers matter more, then you do not have an all-star team and you might want to reconsider your talent pool.
A development methodology should not be used to make your life easier, but a developer’s life easier!
Developers are creative problem solvers (probably better than you are) so let them figure out what works for them. You will get a great deal more respect and have a stronger team that will stay through thick and thin.
Let the developers be free!
This is why I love working for a startup. After working at various large institutions and experiencing all sorts of development methodologies, I am excited to build an environment that focuses on what really matters:
Getting things done with amazing people!
I can’t wait to keep making this a reality with the amazing team that I work with at Artivest!