The Democratic Development Philosophy

Team Work

I have been in software development for over 20 years, throughout these years I have seen a great many techniques applied to curb the software development project failures. As we went from a waterfall approach that has become too long in our ever-demanding instant gratification world to the latest agile methodologies, the big picture and the output qualities are vanishing, and the individual is fading.

Software development today seems to be about wowing the client, whoever that might be, into a too often false sense of comfort about the project’s advances. The sooner there is something to show the better for the development team because the client will be happier. The management of the people in these software team are taking a back seat; it becomes all about that elusive happy client. But can you have a happy client without a satisfied team on the project? Probably, at what cost though?

But can you get both the happy, creative software developer and the happy client?

I believe that it is not only possible but imperative to achieve and that brings me to an agile methodology that I have, and hopefully, you have been using. I call it the “Democratic Development Philosophy” or DDP for short.

First, it is essential not to confuse Agile which is a methodology and Democratic [Software] Development which is a management philosophy; it is vital to distinguish between the two. However, both can and must co-exist to lead the team in a repeatable successful project cycle. Though I have seen Agile referred to as “Democratic Software Development”, see V.Rengarajan who refers to the SDLC and agility of the team, and only touches on the management philosophy, the paper found here.

The principles behind DDP are not only applicable to software development but also to any creative development team, I have only used it in software development. I need to add that I am no expert in this and want to share my experiences of what has worked for me in the past.

There are some requirements to achieving DDP; the team needs to get along and have minimal internal politics, the individuals in the team also need to know and accept that individual ego will not be tolerated. These are important aspects to achieve up front as using DDP also requires every member irrelevant of age, experience or scholar achievements to have the same rights.

In many ways, DDP starts by being a round table exercise where every member has the same voice, the difficulty when starting with DDP is in the leadership. Most managers, architects or team leads have an inherent dictatorship within them, and sometimes it is required, but it must be avoided for DDP to succeed as this will only send the members of the team in a defensive state, the last thing you will want.

In a DDP team, the leader is the voice and the moderator of the team; the leader allows the team to get creative with solutions, nothing gets dismissed or laughed off. The answer to the current dilemma lies within the team, not within an individual. Because this is so, every member needs to speak their mind and give their opinion without judgment from others. It gets tricky, particularly in environments where very different types of characters exist in the team, it is up to the leader to ensure that no one gets oppressed. However, this is only the beginning, as the team’s trust grows in Agile Democratic [Software] Development, it becomes both a philosophy and a methodology where the team naturally creates what I call a brain trust.

Initially, the DDP is used in stand-ups and meetings, as the team blends into a single unit of trust; it becomes a way of life. Each member starts to bring more into the solution culminating into a better more stable and more desirable product.

Most of what follows will become natural to the team; all the leader has to do is maintain the trust as the team gets better and faster.

Share on facebook
Share on twitter
Share on linkedin
Share on pinterest
Share on pocket

Related posts

Leave a Reply

Your email address will not be published. Required fields are marked *